Timestamps and scheduling guides
Daylight saving: nonexistent and repeated local times
Detect clock-change gaps and overlaps, and use explicit offsets or a documented scheduling policy.
Spring creates a gap
When clocks move forward, some local calendar times never occur. A bare local time in that gap does not identify a real instant.
For America/New_York on 2024-03-10, 02:30 is skipped. Check the zone and date together rather than assuming all days contain every clock time.
America/New_York
2024-03-10 02:30:00 → nonexistent local timeAutumn can create two instants
When clocks move backward, a local clock time can occur twice with different offsets. The text alone is ambiguous.
For the repeated 01:30 in New York on 2024-11-03, explicitly choose -04:00 or -05:00 to select the intended instant.
2024-11-03T01:30:00-04:00 → 05:30 UTC
2024-11-03T01:30:00-05:00 → 06:30 UTCChoose a resolution policy
Applications can reject, shift or choose an occurrence, but those choices must be documented. Different libraries can make different defaults.
Nav Tools rejects ambiguous and nonexistent offset-free local datetimes. An explicit offset removes ambiguity for a supplied instant.
Check recurring jobs at transitions
A daily local-time job is not equivalent to a fixed 24-hour timer. The next execution around a clock change depends on the scheduler’s policy.
Preview both transition boundaries in Cron and verify the deployed scheduler. Use UTC recurrence only when a stable UTC time matches the business requirement.