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@eyrie.org) <https://www.eyrie.org/~eagle/>