Dates and time zones: why an order lands on the wrong day

Why an order lands on the wrong day

Shopify stores every timestamp in UTC. Its GraphQL Admin API documents DateTime as an ISO 8601 string with the zone marker Z, and createdAt on an order is set when the customer completes checkout. The ERP needs a date: the posting date of the sales order or invoice. Between the two sits a conversion that is easy to skip.

{
  "name": "#5531",
  "createdAt": "2026-10-01T04:30:00Z",
  "shop": { "ianaTimezone": "America/Los_Angeles" }
}

Taking the first ten characters gives 2026-10-01. Converting to Los Angeles time first gives 9:30 pm on September 30, so the posting date is 2026-09-30. Pacific daylight time is UTC minus 7 hours, which means every order between 5:00 pm and midnight Pacific carries the next day in UTC.

On most days that moves revenue by one day. On the last day of a month it moves revenue into the next month, on September 30 into the next quarter, and on December 31 into the next fiscal year. A store that takes 30% of its orders after 5:00 pm Pacific and has 900 orders on the last day of the quarter books 270 of them in the wrong quarter.

What each system sends and stores

WooCommerce shows why the field name matters. Its documentation's own example has date_created at 15:23 and date_created_gmt at 18:23 for the same moment. Neither carries an offset, so the integration has to know which field is which. Reading the local field as UTC shifts every order by the site's offset.

NetSuite's default for trandate is a trap of its own. An order that waits in a queue overnight and is written without a trandate gets the date of the write, not of the order.

Daylight saving time: the hour that does not exist and the hour that happens twice

Daylight saving time in the United States starts at 2:00 am on the second Sunday of March and ends at 2:00 am on the first Sunday of November. In 2026 those are March 8 and November 1.

A fixed offset does not survive this. -07:00 is correct for Los Angeles in summer and wrong in winter, when it is -08:00. It is correct for Phoenix all year, because Arizona does not observe daylight saving time, except the Navajo Nation. Neither do Hawaii and Puerto Rico. A company with a warehouse in Phoenix and a store set to Los Angeles has two zones that agree from March to November and differ by an hour the rest of the year. The integration stores the IANA name, America/Phoenix or America/Los_Angeles, and lets the time zone database supply the offset per date.

03/04/2026: one string, two dates

In the United States 03/04/2026 is March 4. For a supplier in the United Kingdom, Mexico or most of Europe it is April 3. Both are valid dates, so nothing fails; the delivery date is a month off.

The rule per source is fixed in the mapping: this supplier writes MM/DD/YYYY, that one DD/MM/YYYY. A value is checked against it, and values that cannot be told apart in a new file are sent to review rather than guessed. Days above 12 help: 03/14/2026 can only be March 14. A file where every day is 12 or lower cannot be checked that way, and one supplier that switches format after an Excel round trip produces exactly that. ISO 8601, 2026-03-04, has one reading only. The other ways files break are in supplier CSV and Excel files.

Week numbers: ISO against Excel

A supplier who promises delivery "in week 1" may count weeks in two ways. Excel's WEEKNUM function by default starts weeks on Sunday and numbers the week that contains January 1 as week 1. ISO 8601, which Excel offers as return type 21, starts on Monday and makes the week with the first Thursday week 1.

"Week 1" is January 1 and 2 in one system and January 4 to 10 in the other. A delivery promised in week 2 is either January 3 to 9 or January 11 to 17. The mapping records which system each supplier uses and converts the week to a date range.

Lead time as a duration or as a date

"Ships in 5 business days" and "expected December 3" are two different fields. Converting the first into the second needs a calendar of working days and holidays.

An order on Wednesday, November 25, 2026, with 5 business days:

• Counting weekdays only: November 26, 27, 30, December 1, 2. Ship date December 2.
• Skipping Thanksgiving, a federal holiday on November 26: November 27, 30, December 1, 2, 3. Ship date December 3.

The warehouse's own calendar decides. If it also closes on the Friday after Thanksgiving, the date is December 4. ERPs carry both forms. NetSuite has a lead time in days and an expected receipt date on each purchase order line; Oracle's field help says that date defaults to the date of the purchase order itself. A default that is never overwritten tells the store the stock arrives the day it was ordered. Getting dates like these to the store is the subject of delivery dates.

Cut-off times add a time zone to the calendar. "Order by 2:00 pm ET, ships today" from a warehouse in Ohio means 11:00 am for a buyer in California. A store that shows the cut-off in the buyer's local time has to convert it, and a store that does not convert it promises same-day shipping until 2:00 pm Pacific, three hours after the warehouse stopped picking.

What this means for your integration

We map every date and time with its source zone and format: UTC timestamps converted to the zone your books are kept in, supplier formats declared per source, week numbers converted to date ranges, and lead times counted on your warehouse calendar. Timestamps are stored in UTC and compared in UTC, so a run during the daylight saving change does not skip or repeat records.

In the dry run, orders around a month end are the test: you see per order which posting date it gets in your ERP before anything is booked. The rest of the order mapping is on orders, customers and shipping, and the method on field mapping. Tell us where your store and warehouse are, and we show you which dates move.