[tz] Weird PST8PDT and EST5EDT behavior on Alpine Linux

[Russ Allbery]

Paul Eggert <eggert at 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 at eyrie.org)             <https://www.eyrie.org/~eagle/>