The report goes out at nine. The date column came from Airtable and it is wrong. Not obviously wrong, which would at least be easy to explain to whoever is waiting for it. Wrong by one day. Or by five hours. Or wrong only on the rows where somebody scheduled something for the evening.
You have probably already changed a date format setting and watched it do nothing. Three separate settings decide what shows up in that cell, they live in two different products, and the one most people change first is almost never the one causing the problem.
Work out which of the three you have before you touch anything. It takes about two minutes.
The short answer
Airtable does not store the date you see. It stores an exact instant in UTC and converts it for display. Google Sheets does the same with its own time zone, which belongs to the spreadsheet rather than to you. The value in your report is the output of two conversions and one display format, and any of the three can be the thing that is off.
Match your symptom to the row, then change only that setting.
| What you are seeing | What it usually is | Where the fix lives |
|---|---|---|
| Off by one day, often only on evening or early-morning rows | The Airtable field carries a time, and the stored instant fell into the next calendar day | Airtable, the field's Formatting settings |
| Off by the same number of hours on every row | The spreadsheet is reading the value in a different time zone from the one you expect | Google Sheets, File then Settings |
| Looks correct on screen, sorts or subtracts wrong | The cell holds text that resembles a date | Google Sheets, the cell itself |
| 03/04 landing in the wrong month | The spreadsheet locale reads day-first where the data was written month-first, or the reverse | Google Sheets, File then Settings |
Changing all three at once is how a report ends up wrong in a new way. Change one, refresh, look again.
Off by exactly one day: start in Airtable
Airtable stores dates in Greenwich Mean Time. Its support documentation states this plainly, and every date leaving Airtable, by export or automation or sync, leaves as an instant in UTC.
So a workshop set for 9:00 PM on 31 March in New York is stored as 1:00 AM on 1 April. Nothing has gone wrong. The account manager who booked it sees 31 March, because her browser converts it back. Anything reading the stored value sees 1 April, and your March total is short by one.
That is why the shift hits some rows and not others. Only the times late enough in the evening, or early enough in the morning, cross midnight when converted.
The fix
In Airtable, click the dropdown arrow next to the field name, click Edit field, and open the Formatting section. Three controls there matter:
Include time. If your report only cares about which day something happened, turn this off. A date with no time attached cannot drift across midnight, and this one change resolves most off-by-one-day complaints permanently. Reach for it first. It is also the only one of the three that changes the value itself rather than the display, which is why it is the one that reaches a synced spreadsheet.
Use the same time zone for all collaborators. Leave this off and every collaborator sees the stored instant converted into their own local time, so two people looking at the same record really do see different times. Turn it on and you pick one time zone, GMT by default, that everyone sees.
Display time zone. Turn this on while you diagnose. It puts the zone abbreviation next to the value, which usually ends the argument in about ten seconds.
One thing to hold onto, because it explains most failed fixes: the two time zone settings change what people see in Airtable, not what Airtable stores.
- A CSV export takes the displayed value, so the field's formatting settings carry through to the file.
- A sync or automation reads the stored value, so display settings make no difference to what lands in your spreadsheet.
If you flipped the GMT toggle, watched Airtable change, then found the Sheet unchanged after the next sync, that is exactly what you were seeing.
Off by a fixed number of hours: it is the spreadsheet
If every row is out by the same amount, always, in the same direction, this is not a data problem. It is an offset, and it is coming from the spreadsheet.
Every Google spreadsheet carries its own time zone and locale. Per spreadsheet, not per account, so a file created by a colleague in Berlin keeps Berlin's settings after you copy it, rename it, and hand it to a client in Chicago. Nobody thinks to check, because nothing on screen announces it.
Open File, then Settings. Under General you get a Locale menu and a Time zone menu. Set both, then click Save settings. Google's documentation is direct about the consequence: "it changes for the entire spreadsheet. Everyone working on it will see the changes, regardless of their location."
That time zone is what NOW() and TODAY() are calculated against, and what any formula doing date arithmetic uses as its reference point. Set it to the time zone the report is read in, not the one you happen to be sitting in this week.
Worth saying plainly, since this is our own tool: Airtable to Sheets writes a date-time as the stored UTC clock time in year-month-day order, for example 2026-04-01 01:00:00. It does not shift the value into a local zone, because it has no way to know which local time your report is read in. A booking showing 9:00 PM New York in Airtable arrives as 01:00 the next day. Same instant, different clock. If the cell has to read local, add a helper column that offsets it, and expect that fixed offset to be an hour out during daylight saving changeovers.
Right on screen, wrong in a formula
The most frustrating of the three, because everything looks fine. The column reads 2026-03-05, the eye accepts it, then the sort puts December before February and a subtraction returns an error.
A Google Sheets cell holds a date as a number. Day zero is 30 December 1899 and every date since counts forward from there, with the time of day carried as a fraction of a day. The date on screen is a costume the number is wearing. If the cell holds text that merely looks like a date, no number exists underneath, so sorting falls back to alphabetical order and arithmetic has nothing to work with.
Two ways to tell in five seconds:
- Look at the alignment. Google Sheets right-aligns real dates and left-aligns text. A column of dates hugging the left edge is a column of text.
- Ask it. Put
=ISNUMBER(A2)in a spare cell, pointing at a date cell.TRUEmeans a real date.FALSEmeans text dressed as one.
The fix
Select the column and apply Format, then Number, then Date or Custom date and time. If the values were already real dates in a format you disliked, they redraw and everything downstream starts working.
If the values are text, changing the format will not touch them, because there is no number to reformat. Set the spreadsheet locale correctly first, then have the column written again. Fixing the locale afterwards does not convert anything already sitting in the sheet.