Question
Ambiguous local time resolution during DST transitions with IANA zones
Rey Cedar
0 reputation · 27 Jun 2021, 07:08 UTC
37.2K views1
Loading…
0 reputation · 27 Jun 2021, 07:08 UTC
AlmaLinux relies on the IANA Time Zone Database packaged with glibc, and administrators set the system zone via timedatectl set-timezone or by updating the /etc/localtime symlink. Applications perform date conversion by reading the TZ environment variable or the system zone.
During a daylight-saving transition, a local timestamp such as 02:30 on the fallback day occurs twice. The tzdata rules define the UTC offset for each occurrence, but the C library and higher-level runtimes may normalize the ambiguous value to the earlier or later UTC instant, or they may return an error indicator. The documentation does not prescribe a single default for all consumers, leaving the outcome dependent on the calling code and its locale settings.
The system zone is an IANA identifier (for example America/New_York), not a POSIX-style TZ string. Services started before a zone change continue to use the old offset until they are restarted or re-read the zone information. This adds uncertainty when a deployment changes the zone and expects immediate consistency across all processes.
Which system-level component ultimately decides how an ambiguous local time is mapped to UTC when the zone is an IANA name? Does systemd-timedated expose any hint or policy that applications can query? Are there documented differences between glibc's localtime_r and common language runtimes (Python, Java, Go) on AlmaLinux 9 and 10?
35275 reputation · 27 Jun 2021, 17:06 UTC
The mapping of an ambiguous local time to UTC is decided by the C library, glibc, using the IANA tzdata that AlmaLinux ships. systemd-timedated does not decide the mapping and does not expose a public hint or policy for ambiguous times that applications can query. It only manages the system zone via /etc/localtime symlink and timedatectl.
For an IANA zone such as America/New_York, glibc's localtime_r / mktime uses the tzdata transition table. When no explicit disambiguation is supplied, glibc defaults to the earlier occurrence of the ambiguous wall clock, i.e., the first UTC instant with that local time. This is the POSIX "fold" default.
Likely explanation: differences you observe are from application-level disambiguation, not from systemd. Confirmed behavior: glibc provides the fold flag via struct tm.tm_gmtoff handling in recent versions, and runtimes expose it differently.
Note: Python's older pytz library uses localize with is_dst flag and does not follow zoneinfo semantics, which can cause divergent results.
almalinuxtimedatectl status and rpm -q tzdata glibc.To give a precise recommendation for your deployment, one missing diagnostic detail is needed: which runtime versions and which Python library, zoneinfo vs pytz, are in use in the services that process the ambiguous timestamps. The default changes if an application explicitly sets fold/is_dst.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.