tzinfo local-seconds-to-utc offset policy at DST fallback

Question

tzinfo local-seconds-to-utc offset policy at DST fallback
Goal: Convert a regional wall-clock time, for example 01:30 on a fall-back date in America/New_York, to a UTC instant using Racket's tzinfo collection.
The local-time-to-UTC mapping is not one-to-one around daylight-saving changes. A repeated local time can correspond to two UTC offsets, while a skipped local time corresponds to none. It is unclear whether local-seconds-to-utc selects the earlier offset, the later offset, raises an exception, or depends on the installed tzdata version and platform.
Because seconds->date with #:local? #t follows the operating system zone, results may differ across CI runners unless an explicit zone is pinned. This question assumes the full Racket distribution with tzinfo available and does not cover racket/date alone.
Which UTC offset does tzinfo choose for an ambiguous local time? Does it raise an exception for a nonexistent local time? Is the behavior stable across Racket releases?

Wasi · Answer

Answer to the exact question
The local-seconds-to-utc function in Racket’s tzinfo collection always returns a single UTC instant. For ambiguous local times (the hour that repeats on a DST fallback), it selects the earlier UTC offset – the one that is still in effect when the clock first rolls back. For non‑existent local times (the hour that is skipped on a DST spring‑forward), the function does not raise an exception; instead it maps the requested local time to the next valid instant in the zone’s chronology, effectively “shifting” the time forward by the length of the gap.
Why this happens

Racket’s tzinfo is a thin wrapper around the system’s zoneinfo implementation (libtz or the OS’s tzdata database). These libraries expose a deterministic mapping that picks one offset for a given local time.
The API does not provide a :fold or similar flag, so the choice is hard‑coded: earlier offset for ambiguity, forward shift for gaps.
Because the function returns a single seconds value, it cannot express the dual possibility of an ambiguous time.

Is the behavior stable across Racket releases?
Within a given Racket release the algorithm is fixed, but the actual offset chosen can change when the underlying tzdata database is updated. If you upgrade the OS or install a newer tzdata version, the same wall‑clock time may map to a different UTC instant. Racket itself does not change the selection policy unless the library code is modified.
Practical verification
To confirm the offset for a specific date, you can run a short snippet:
(require tzinfo)
(define zone (zone-info "America/New_York"))
(define t (local-seconds-to-utc zone 1698804600)) ; 2023‑11‑05 01:30 local
(displayln t)
Replace 1698804600 with the Unix timestamp for the local time you want to test. Compare the printed UTC value against a trusted converter (e.g., timeanddate.com) to see whether the DST or standard offset was applied.
What you might need to know next
Because the mapping depends on the OS’s tzdata, it helps to know which database you’re running. If you’re seeing unexpected results, check:

The operating system (Linux, macOS, Windows).
The version of the tzdata package installed (e.g., tzdata 2025a).
The Racket version (e.g., 8.3).

Providing that diagnostic detail can clarify whether a difference is due to a database update or a Racket bug.

tzinfo local-seconds-to-utc offset policy at DST fallback

tzinfo local-seconds-to-utc offset policy at DST fallback

1 answer

Answer to the exact question

Why this happens

Is the behavior stable across Racket releases?

Practical verification

What you might need to know next

Your perspective belongs here.

0 question comments