Bash 5.0 printf TZ ambiguous DST transition handling remains undefined

Resolution of DST Ambiguity in Bash 5.0

Bash 5.0 does not implement its own logic for resolving Daylight Saving Time (DST) ambiguities. Instead, it delegates date formatting via printf %(...)T to the host system's C library (libc) using the strftime() function. Because Bash passes an absolute epoch value (seconds since 1970-01-01 00:00:00 UTC) to the system call, the output is deterministic for a specific environment, even if the resulting local wall-clock time is ambiguous.

Likely Explanation of Behavior

Ambiguity in DST transitions typically occurs when converting a local time back to an epoch (e.g., deciding if 02:30 AM occurs before or after a clock shift). However, printf %T operates in the opposite direction: Epoch → Local Time. Since an epoch value represents a unique point in linear time, there is no ambiguity for the system to resolve; it simply applies the offset defined by the current tzdata and libc implementation for that specific moment.

The perceived "undefined" behavior usually stems from two external variables rather than Bash itself:

• libc Implementation: glibc (Linux) and BSD/macOS libc may handle TZ strings or edge-case transitions differently.
• tzdata Versions: If the system's time zone database is updated, the offset for a historical epoch may change, altering the printf output.

Verification Steps

To verify how your specific environment resolves a transition, use a known epoch value during a shift (e.g., Europe/Paris transition). Run the following scoped commands:

# Example: Test a specific epoch with a defined TZ
TZ="Europe/Paris" printf "%(%Y-%m-%d %H:%M:%S)T\n" 1742948400

# Check the system's tzdata version to correlate results
zdump -v Europe/Paris | tail -n 20

Diagnostic Requirement

To provide a more precise mapping of the behavior you are seeing, please specify the Operating System and libc version (e.g., Ubuntu 22.04 with glibc 2.35), as this is the primary driver of the formatting logic.