Salesforce import problem

Salesforce import dates are off by one day

Nothing failed. The job reported success, every row went in, and every date is wrong by 24 hours. Here is exactly where the day goes, and how to get it back.

Last updated 14 July 2026 6 min read

The short answer: find out whether the field is a Date or a Date/Time, because they behave completely differently. For a Date field, send a bare yyyy-MM-dd string with no time component at all — Salesforce documents no other format for it, and an offset is explicitly not supported. For a Date/Time field, send an unambiguous instant with an explicit offset or Z — 2026-07-01T09:00:00Z. The day disappears when some tool in the chain stamps your bare date with midnight in its own local timezone and then converts that instant to UTC.

This one is dangerous because nothing errors

Most import problems announce themselves. A restricted picklist rejects the row. A bad number fails to convert to the field's type. You get a failure log, you fix it, you move on.

A timezone shift produces none of that. The batch succeeds, the record count matches, and every close date, renewal date and birthday is simply one day off until a report or a customer notices. Treat it as silent corruption, not an error: the job is not to stop a failure, it is to find out whether the data already in your org is wrong.

Date and Date/Time are not the same field

Almost every version of this bug starts here. Salesforce's API reference is blunt about it: date fields "contain no time value", while a Date/Time is a full timestamp.

Field type	What is stored	Format the API accepts	Converted for the viewer?
Date	A calendar date. No time.	`yyyy-MM-dd` — an offset is not supported	No. Shown as stored.
Date/Time	An instant, held in UTC.	`yyyy-MM-ddTHH:mm:ss.SSSZ` or the same with a `+/-HH:mm` offset	Yes. Rendered in each viewing user's timezone.

That last column is the whole bug. A Date/Time is stored once and displayed differently to everyone who looks at it. If your column means "a day" — a close date, a contract start, a date of birth — it has no business being in a Date/Time field at all.

The four places the day goes missing

1. Your loader stamped local midnight onto a bare date

Data Loader has a Time Zone setting, and its documented behavior explains the classic version of this bug: if a date value does not include a time zone, that setting is used — and if no value is specified, the time zone of the computer where Data Loader is installed is used instead.

So on a laptop in Berlin (UTC+2 in summer), 2026-07-01 becomes 2026-07-01T00:00:00+02:00 — which is 2026-06-30T22:00:00Z in UTC. The day is gone. On a laptop in Chicago (UTC-5) the same file survives untouched, which is why this bug looks maddeningly intermittent across a team loading "the same" file. Daylight saving adds a second wobble: the offset depends on the date, so a file spanning a DST boundary can shift some rows and not others.

2. Nothing is corrupted — you are looking at it from another timezone

Salesforce stores every Date/Time in UTC and renders it in the timezone of the user reading it. A value written as 2026-07-01T00:00:00Z is genuinely, correctly stored — and a colleague in Los Angeles will genuinely, correctly see 30 June, 5:00 PM. Two people can disagree about the day and both be looking at good data.

Before you rewrite any file, check your own setting: personal settings → Language & Time Zone. It changes what you see, never what is stored — and reports follow the same rule, so a report grouped by a Date/Time field groups by your timezone.

3. Excel rewrote the column before Salesforce ever saw it

Serial numbers leak out. Excel holds dates as serial numbers. A bad export can hand Salesforce 46204 instead of 2026-07-01 — which is not a date at all, and lands you on a type conversion error instead.
Round-tripping reformats. Open a clean yyyy-MM-dd CSV in Excel, save it, and the column can come back out as 7/1/2026 in your locale's short-date format — ambiguity you had already removed.
The 1900 leap-year quirk. Microsoft documents that Excel treats 1900 as a leap year and will not fix it, for serial-date compatibility with Lotus 1-2-3. It bites only if you convert serials to dates with hand-rolled arithmetic: date libraries use an 1899-12-30 epoch precisely to absorb that phantom 29 February, and a naive epoch leaves you off by exactly one day.

4. An ambiguous format, resolved by someone else's rules

Data Loader has a Use European date format option (dd/MM/yyyy), and the Data Import Wizard expects date values to match the locale of the user running the import. So 03/04/2026 means two different things to two different tools. Those shifts are usually bigger and more visible than a day — but the cure is the same: stop shipping formats that have to be interpreted, and ship ISO.

Fix it

Find out what the field actually is. Setup → Object Manager → your object → Fields & Relationships → the field → Data Type. If it says Date/Time and your data means a day, that mismatch is the bug, and no amount of file editing will fix it permanently.
Write Date columns as bare yyyy-MM-dd. No time, no Z, no offset. Salesforce documents that format for date fields, and documents that specifying an offset for a date is not supported. Anything carrying a time is outside the documented format — do not gamble on how it gets truncated.
Write Date/Time columns as an explicit instant. 2026-07-01T09:00:00Z if the source is already UTC, or 2026-07-01T09:00:00-05:00 if it is 9 AM in Chicago. If you send a time with no offset, something downstream chooses one for you, and it will not tell you which.
Set Data Loader's Time Zone deliberately. Settings → Time Zone. Use the timezone the source data is really in (or GMT if the values are already UTC), and set the same value on every machine on the team. Left blank, every teammate's laptop clock is part of your pipeline.
Keep Excel out of the column. Do not double-click a CSV to edit it. Bring it in through Data → From Text/CSV and set the date column's type explicitly, or format the column as Text before anything is typed into it.
Verify against the record, not a report. Query the field back with SOQL, or open a record and compare it to the source row. Checking a Date/Time in a report re-applies the very conversion you are trying to diagnose.

Date field         2026-07-01                 correct
Date field         2026-07-01T00:00:00Z       do not send this
Date/Time field    2026-07-01T09:00:00Z       correct, unambiguous
Date/Time field    2026-07-01T09:00:00-05:00  correct, unambiguous
Date/Time field    2026-07-01 09:00:00        someone else picks the timezone

Stop shipping the shift

Every step above works with the tools you already have. What none of them gives you is a look at the value before it is written — the only moment a silent one-day error is cheap to fix.

That is the part INQUA's import tool is built for. Its Parse date transformation reads your column against the exact source format you name, so 01/07/2026 is never guessed at — a value that does not match the format you declared is a cell error, not a silent reinterpretation. Type the target column as Date and the time component is dropped, so what leaves the tool is a calendar date rather than a timestamp waiting to be shifted. A value that does arrive carrying an offset is converted to UTC deterministically, instead of being re-read in whatever timezone the server happens to be running in. The preview shows you the converted value cell by cell and flags the ones it cannot parse — and it reads .xlsx and .xlsm directly, so a CSV round-trip never gives Excel the chance to reformat the column on save.

Be clear about the limits. A preview can check the shape and type of a value; it cannot run your org. Required fields, validation rules, triggers, Flows and duplicate rules all execute on the Salesforce side, and no tool of ours simulates them. INQUA also does not export records out of Salesforce and does not schedule jobs. It is free during early access and works on a plain file with no Salesforce connection at all — you can use it purely to produce a clean, typed workbook and load that however you like.

After the fix

Re-run and check a handful of records against the source rows by hand. If the dates are right but rows are now rejected outright, you have uncovered the next problem — often a value that will not convert to the field's type. The Salesforce import error hub covers the rest.

And if the shift returns every time somebody new runs the load, the file is not the problem — the machine-local timezone inside your loader is. That is one of the better reasons to look at a Data Loader alternative, and to import Excel without the CSV round-trip.

Frequently asked

Why are my Salesforce import dates one day earlier than the file?

Because a bare date with no timezone gets stamped with midnight in some tool's local timezone, then converted to UTC. Midnight on 1 July in a UTC+2 zone is 22:00 on 30 June in UTC, so the day is lost. Machines behind UTC do not lose it, which is why the same file works for one teammate and not another.

What format should a Date field be in a Salesforce import?

A bare yyyy-MM-dd string, with no time, no Z and no offset. Salesforce documents that format for date fields and states that specifying an offset for a date is not supported. Anything carrying a time component is outside the documented format, so do not rely on how it gets truncated.

What format should a Date/Time field be?

An explicit instant: yyyy-MM-ddTHH:mm:ss.SSSZ, or the same with a +/-HH:mm offset, for example 2026-07-01T09:00:00Z or 2026-07-01T09:00:00-05:00. If you send a time with no offset, a tool somewhere in the chain chooses a timezone on your behalf and will not tell you which one it picked.

Does the Data Loader Time Zone setting fix this?

It fixes the loader's half of it. The documented behavior is that when a date value has no time zone, the Time Zone setting is used, and when no value is set, the timezone of the machine running Data Loader is used. Set it deliberately, to the timezone your source data is actually in, and set the same value on every machine on the team.

Why do two users see different dates on the same record?

Because Date/Time values are stored in UTC and rendered in each viewing user's timezone. Nothing is corrupted. Check personal settings, Language and Time Zone, before rewriting any file. If the value should not depend on who is looking at it, the field should probably be a Date, not a Date/Time.

Why does Excel change my date column?

Excel holds dates as serial numbers and reformats them to your locale on save, so a clean yyyy-MM-dd column can come back out as 7/1/2026 — or as a raw serial number, which Salesforce cannot read as a date at all. Import the CSV through Data, From Text/CSV and set the column type, rather than double-clicking the file.

Is a wrong date an import error?

No, and that is what makes it expensive. The job succeeds, the row count matches, and nothing is logged. Unlike a rejected picklist value or a type conversion failure, a timezone shift is silent, so the corrupted data sits in your org until a report or a customer surfaces it. Check the records after every date-bearing load.