Paul Eggert <eggert@cs.ucla.edu> writes:
On 2024-03-03 22:51, Russ Allbery via tz wrote:
This probably belongs on an Alpine-specific mailing list, but this was odd enough that I'm wondering if I'm missing something about the interpretation of legacy POSIX time zone strings....
$ env TZ=PST8PDT date -R -d @1643145780 Tue, 25 Jan 2022 14:23:00 -0700
That's not a POSIX time zone setting. However as you noted, "PST8PDT" is a TZDB Zone (this is for compatibility with pre-POSIX systems), so this smells like a bug in how musl interprets TZif files.
I know I was going to make at least one silly mistake. Thanks, I keep forgetting that those are special even though the syntax looks somewhat similar. (https://developer.ibm.com/articles/au-aix-posix/ seems to make the same mistake for EST5EDT, or maybe on AIX those are POSIX time zone settings?)
That's odd. Perhaps the PST8PDT file is not actually being consulted? (You can use strace to tell.)
Oh, good idea. This does appear to be the case, so this is clearly not a tz issue. I'm not sure why or what's going on instead, but it must be something internal to either the Alpine build of busybox or to musl. The only system calls that are not memory management, signal handling, or other internals are: clock_gettime64(CLOCK_REALTIME, {tv_sec=1709607584, tv_nsec=678348433}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=28, ws_col=80, ws_xpixel=817, ws_ypixel=562}) = 0 writev(1, [{iov_base="Tue, 25 Jan 2022 14:23:00 -0700", iov_len=31}, {iov_base="\n", iov_len=1}], 2) = 32 On my Debian system, busybox does load the zone file, so this seems to be specific to Alpine or musl. Thanks! -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>