On Tue, 11 Jun 2024 at 21:52, Grisha Levit <grishale...@gmail.com> wrote:
> POSIX says about the TZ variable: > > If the dst field is specified and the rule field is not, it is > implementation-defined when the changes to and from DST occur. > > musl seems to interpret `TZ=EST5EDT` as having DST always in effect, > causing the tests that rely on the glibc behavior (of defaulting to > America/New_York transition rules) to fail. > It appears that glibc treats the 6 US timezones not as specifications using an implementation-defined rule, but rather references to files with names like /usr/share/zoneinfo/PST8PDT. Perhaps the issue is that systems using musl don't include the tzdata package? If the tests are being updated, please can southern-hemisphere daylight saving also be checked. For thoroughness, I suggest testing: * Chatham Islands time TZ=NZCST-12:45NZCDT,M9.5.0/2:45,M4.1.0/3:45 * Australian NSW & Vic time TZ=AEST-10AEDT,M10.1.0,M4.1.0/3 * Australian SA time TZ=ACST-9:30ACDT,M10.1.0,M4.1.0/3 * British time TZ=GMT0BST,M3.5.0/1,M10.5.0 * Central European time TZ=CET-1CEST,M3.5.0,M10.5.0/3 I also note a minor bug/issue with printf in Bash 5.3-alpha: the builtin printf treats TZ=CET-1CEST,M3.5,M10.5/3 as if it were oddly-named UTC. For 30+ years it has been my experience that the '.0' for Sunday is not required, either in practice or (I *think*) by the POSIX specification. -Martin
