Ambiguous local time resolution during DST transitions with IANA zones

Context

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.

Unresolved behavior

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.

Constraints

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?