On 2026-03-06 18:08, Robert Elz via tz wrote:
std and dst Indicate no less than three, nor more than {TZNAME_MAX}, bytes that are the designation for the standard (std) or the Daylight Saving (dst) timezone.where indeed PT would not be usable, but we have no reason to care about that
Unfortunately we do. See Internet RFC 9636 section 3.3 <https://www.rfc-editor.org/rfc/rfc9636#name-tzif-footer>. It says the TZ strings embedded in TZif files need to conform in this respect to POSIX.1-2017, which has that three-byte minimum.
Moreover, RFC 9636 section 4 <https://www.rfc-editor.org/rfc/rfc9636#name-interoperability-considerat> says "Time zone designations MUST consist of at least three (3) and no more than six (6) ASCII characters from the set of alphanumerics, '-', and '+'." These restrictions also derive from POSIX.
Although we could relax these restrictions in later RFCs, that's not something we could reasonably expect all downstream TZif readers and producers to implement by November, so for now the restrictions do impinge on what we can put into America/Vancouver for this issue.
Besides, alphabetic time zone abbreviations are problematic given their ambiguity and lack of standardization, and so I doubt whether it'd be wise to relax the restrictions and encourage use of shorter abbreviations like "PT" or (shudder!) "O". We have trouble enough as it is with these things.
the idea that a timezone has a constant offset from UTC (for the "timezone" variable) and either one or two names (no more) for timezone name abbreviations is all obsolete garbage,
I quite agree, and POSIX.1-2024 started the ball rolling on getting rid of that garbage. Alas the job is still incomplete. (This is veering off into a different subject of course.)
