[tz] Weird PST8PDT and EST5EDT behavior on Alpine Linux

[Russ Allbery]

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.  There is probably some
obvious answer that I will feel dumb for not spotting.

$ cat /etc/alpine-release 
3.19.0
$ apk list tzdata
tzdata-2023d-r0 x86 {tzdata} (Public-Domain) [installed]
$ apk info --who-owns /bin/date
/bin/date symlink target is owned by busybox-1.36.1-r15

$ env TZ=PST8PDT date -R -d @1643145780
Tue, 25 Jan 2022 14:23:00 -0700
$ env TZ=EST5EDT date -R -d @1643145780
Tue, 25 Jan 2022 17:23:00 -0400

Why would the system decide that time stamp should use daylight saving
time?  The system time zone is set to UTC, so it shouldn't be some sort of
contamination from it.  Or is this some odd bug in the busybox date
command?  It works correctly with busybox 1.36.1 on a Debian system,
though:

% busybox env TZ=PST8PDT date -R -d @1643145780
Tue, 25 Jan 2022 13:23:00 -0800

The Alpine Linux system in question does have PST8PDT and EST5EDT files in
/usr/share/zoneinfo.  The Olson time zone identifiers do work as expected:

$ env TZ=America/Los_Angeles date -R -d @1643145780
Tue, 25 Jan 2022 13:23:00 -0800
$ env TZ=America/New_York date -R -d @1643145780
Tue, 25 Jan 2022 16:23:00 -0500

(We ran into this because it caused test failures in tests of INN's date
parsing library.  I wrote those tests eons ago and they used PST8PDT as
the time zone because when I wrote them there were still some INN users
who were using systems that didn't use the Olson database.)

-- 
Russ Allbery (eagle at eyrie.org)             <https://www.eyrie.org/~eagle/>