A cutoff needs a location as well as a time
“Orders before two ship today” is incomplete unless the team knows which clock, which date and which qualifying order state the rule uses. Storefront time, warehouse time and a software scheduler's UTC time can all be different. The change back to standard time is a useful moment to check whether they still describe the same operating promise.
NIST states that U.S. daylight saving time in 2026 ends November 1 at 2 a.m. local time, when the clock returns to 1 a.m. in locations observing the change. Not every U.S. location observes daylight saving time. Verify the actual warehouse's zone rather than applying one national offset. NIST daylight saving time rules.
Follow one local cutoff through two dates
We calculated this example for a hypothetical warehouse using America/New_York and an unchanged 14:00 local cutoff. It is not a carrier schedule or a provider's service commitment.
| Operating date | Local cutoff | Equivalent UTC time |
|---|---|---|
| October 30, 2026 | 14:00 EDT, UTC−04:00 | 18:00 UTC |
| November 2, 2026 | 14:00 EST, UTC−05:00 | 19:00 UTC |
A job fixed at 18:00 UTC would run at 13:00 New York time on November 2. That is an hour earlier than the intended local cutoff. Whether this causes a problem depends on what the job does: closing an order wave, exporting a file and displaying a customer promise are different operations.
The calculation does not mean every scheduled job should move. Some processes are deliberately fixed in UTC. Write down the intended rule first, then check the configuration against it. Confirm the carrier pickup separately; a local cutoff does not establish when a vehicle will arrive.
The repeated hour needs an unambiguous record
On November 1 in New York, 01:30 occurs twice. The first occurrence, with offset −04:00, is 05:30 UTC. The second, with offset −05:00, is 06:30 UTC. An event log containing only “01:30” cannot distinguish them.
For order histories, ask for timestamps that retain the UTC instant or an explicit offset alongside the displayed local time. Preserve the order and event identifiers too. Two events with the same displayed hour are not necessarily duplicates, and a repeated wall-clock time is not evidence that an order moved backward through the warehouse.
Use a small acceptance set
We designed four checks for the operations and integration owners to run in an approved test environment. These are proposed checks, not tests we performed on a warehouse system.
1. An eligible order immediately before the agreed local cutoff receives the intended operating-day assignment. 2. An order immediately after it receives the intended later assignment. 3. Two distinct events in the repeated hour remain separate and correctly ordered by their actual instants. 4. A held order released after cutoff follows the documented release rule rather than inheriting an earlier creation time by accident.
Use fictional orders and the warehouse's actual definition of eligibility. Payment, inventory availability and release status may matter more than the original order-created timestamp. Record expected and actual results, not just whether the screen looks reasonable.
Close the loop with the customer promise
After checking the warehouse rule, compare it with the storefront wording and support team's instructions. If one says Eastern time and another says warehouse local time, resolve the mismatch before the next busy day. Keep weekends, holidays and agreed operating days visible.
A one-page record of the zone, cutoff, qualifying state, scheduler behavior and pickup confirmation is enough to make the conversation concrete. The point is not to change every clock. It is to ensure that every team is using the same definition of “today.”
Related reading
Sources
- https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst — accessed 2026-10-26