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/>

On 3/4/24 19:52, Đoàn Trần Công Danh via tz wrote:

But seems like nothings was enforced if rule isnot given in the timezone, which makes it open to intepretion.

Musl inteprete that as no transition at all [2].

Thanks, that explains things. TZDB has a TZDEFRULESTRING setting that specifies the transitions in this situation; it defaults to US rules, so musl and TZDB always disagree about TZ settings like TZ='PST8PDT'. In TZDB, though, TZDEFRULESTRING is not used for PST8PDT and EST5EDT, as these are one of a small set of Zones that emulate the old System V behavior except with later US law changes taken into account. Another way to put it: for musl the two settings TZ='PST8PDT' and TZ='pst8pdt' agree except for the case of time zone abbreviations, and neither TZ setting ever uses daylight saving time. For TZDB, though, those two TZ settings agree only back to 2007; for earlier timestamps, TZ='PST8PDT' follows historical US behavior for standard time (and thus agrees with TZ='America/Los_Angeles' for all timestamps after 1883-11-18 at noon) whereas TZ='pst8pdt' disagrees with historical behavior by assuming current (2007 and later) rules for DST transitions before 2007. These behaviors all conform to POSIX.

Rich Felker <dalias@libc.org> writes:

If you want to use a file by that name, the safe way to request that is by prefixing it with a colon, as in TZ=:PST8PDT

We're going to change the test to use America/Los_Angeles by default and only fall back if that doesn't work (probably should have done that about fifteen years ago), but for the record, PST8PDT was for support for very old commercial UNIXes where I believe that was the only recognized style of TZ setting, and I'm pretty dubious that the POSIX-introduced :PST8PDT syntax would work there. One can quite reasonably argue that any system that doesn't understand America/Los_Angeles is at this point a museum piece, so I don't think this is a hugely important issue, but I don't think it has that obvious of a solution. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Guy Harris <gharris@sonic.net> writes:

On Mar 5, 2024, at 12:56 PM, Russ Allbery via tz <tz@iana.org> wrote:

...

but for the record, PST8PDT was for support for very old commercial UNIXes where I believe that was the only recognized style of TZ setting, and I'm pretty dubious that the POSIX-introduced :PST8PDT syntax would work there.

That TZ syntax dates back at least to System III:

http://www.bitsavers.org/pdf/att/unix/System_III/UNIX_Users_Manual_Release_3...

(see CTIME(3C)), which did not support anything tzdb-related, and didn't even support the more elaborate POSIX TZ syntax to include rules.

I don't see any reference to the leading colon in that documentation. Am I just missing something? It seems to support what I said: PST8PDT was supported, but :PST8PDT was not. If an environment variable named TZ is present, asctime uses the contents of the variable to override the default time zone. The value of TZ must be a three-letter time zone name, followed by a number representing the difference between local time and Greenwich time in hours, followed by an optional three-letter name for a daylight time zone. For example, the setting for New Jersey would be EST5EDT. -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

Guy Harris <gharris@sonic.net> writes:

On Mar 5, 2024, at 2:03 PM, Russ Allbery <eagle@eyrie.org> wrote:

...

It seems to support what I said: PST8PDT was supported, but :PST8PDT was not.

Yes. As I indicated, they didn't have tzdb code (if they did, that would be a surprise, as the tzdb project didn't exist in 1979/1980), and they didn't support any POSIX extensions to TZ (if they did, that would be a surprise as, at least according to https://en.wikipedia.org/wiki/POSIX, the first POSIX standard came out in 1988).

Ah, sorry, I had just misunderstood you. Thank you for the confirmation and reference! Basically, to summarize, up until now I think it was possible to set TZ to PST8PDT and have it work essentially everywhere, no matter how old the edition of UNIX, thanks to the backward compatibility file in tzdata. I think musl may have been the first place where this broke somewhat intentionally. This is not a big deal and I'm not sure I'm arguing that musl should change; I expect interfaces to change over time and it's probably time to assume everyone supports the Olson identifiers. But it is a change in the portability landscape, if a minor one. (Probably one that's been around for a while and I just never noticed because I hadn't been running the INN test suite on Alpine Linux.) -- Russ Allbery (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>

On 2024-03-06 07:39, James Cloos via tz wrote:

(I must say it was a bit anoying that the library kept the original definition of EST5EDT et alia rathar than moving with the legislation. But only a bit.)

So Openwrt uses pre-2007 US daylight saving rules for TZ='EST5EDT'? That's puzzling. I thought Openwrt is based on musl, which ignores DST for that TZ setting (a behavior that POSIX allows). I'm a bit curious as to what's going on there.

So I have to use EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00 for the timezone. (The explicit /2:00:00 might be avoidable, but the use of self documenting data can be beneficial.)

For a fully self-documented TZ setting you could use this: <EST>+05:00:00<EDT>+04:00:00,M3.2.0/+02:00:00,M11.1.0/+02:00:00 However, this sort of thing tends to be error-prone; e.g., suppose I forgot a colon? 'zic' attempts to generate the shortest equivalent TZ setting. On my machine /usr/share/zoneinfo/America/New_York ends with this equivalent: EST5EDT,M3.2.0,M11.1.0 which I find more readable. I'm used to TZ strings, though, so that colors my opinion.

On Mar 8, 2024, at 11:02 AM, Rich Felker via tz <tz@iana.org> wrote:

It's not so much that we ignore it (it's present in tzname[1], and would get applied if you use mktime with tm_isdst=1), just that, in the absence of a transition rule for it, it's never considered active. I don't think this is a particularly good behavior (even though it is allowed by POSIX) but nothing great has been proposed as an alternative.

The executive summary of this thread appears to be: Use XXXnnnYYY TZ settings at your own risk, as there's no guarantee how they'll behave. If you want predictable behavior, either use POSIX settings or, if tzdb is present, tzdb settings.

On 2024-03-08 10:39, Guy Harris via tz wrote:

According to at least one page on IBM's support web site, "The default timezone format for AIX 6.1 and AIX 7 is Olson Time":

https://www.ibm.com/support/pages/managing-time-zone-variable-posix

Is that no longer the case?

I just checked, and AIX 7.3 (the latest release) supports TZ settings like TZ='America/Los_Angeles' and has files like /usr/share/lib/zoneinfo/America/Los_Angeles.

On Tue, Mar 05, 2024 at 04:47:02PM -0800, Paul Eggert wrote:

On 3/5/24 12:12, Rich Felker via tz wrote:

...

Yes, it's not clear to me (POSIX doesn't seem to specify) what the default rules should be when none are specified. However, it is clear that these strings meet the syntax for the POSIX TZ form, and thus musl does not attempt to interpret them as filenames, which could result in behavior contrary to the specified meaning.

Although TZDB interprets them as filenames, that is OK because the TZDB filenames have the specified meaning. Each TZDB Zone whose name has the form of a POSIX.1-2017 TZ string implements a set of transitions compatible with the corresponding POSIX TZ setting.

Long ago that wasn't the case: there were Zones like "GMT-12" that weren't compatible with POSIX even though their names took the POSIX forms. But that bug was fixed decades ago, in tzdata 94d (1994-02-24), and we no longer need to worry about that possibility.

Interesting idea we could consider: if the TZ string matches POSIX format for a zone with DST but without any rule portion, load a file and accept it if the zones are consistent (all name/offset pairs match) -- so that it's effectively just defining the transition date rules. Rich