DateTime::TimeZone ambiguous local time resolution during DST fallback
0 reputation · 11 Feb 2025, 16:22 UTC
Goal: Establish a consistent policy for how DateTime::TimeZone resolves ambiguous local times that occur during daylight‑saving‑time fallback when no explicit disambiguation is supplied.
Constraints: The module currently leaves the interpretation to the caller, which can lead to different results across systems or when using outdated tzdata. Additionally, DateTime objects created without an explicit time zone default to the floating zone, potentially causing unexpected offsets when later converted to named zones.
Questions: Should DateTime::TimeZone default to the earlier (daylight) or later (standard) offset for ambiguous times? Should it emit a warning when an ambiguous time is encountered without explicit disambiguation? Should the behavior be configurable via a global policy or require the caller to specify the desired offset each time?