On 2026-07-25 11:59, Guy Harris wrote:
On Jul 20, 2026, at 6:31 AM, Robert Bastian <[email protected]> wrote:
Personally I think TZDB should move away from abbreviations and just use %z.
Presumably meaning "use the offset from UTC in the ISO 8601 format "-0430" (meaning
4 hours 30 minutes behind UTC, west of Greenwich)", to quote C23.
More typically it'd be something like "-04". The trailing "30" would be
needed only if Newfoundland follows suit. This is what %z has long done.
From a quick look, POSIX does not appear to require alphabetic abbreviations for the
time zone if the TZ setting specifies an entry in "an implementation-defined
timezone database", so I guess we might be able to get away with that.
POSIX required support for numeric abbreviations like "-04" starting in
POSIX.1-2001, and these abbreviations have been in TZif files' TZ
strings since release 2016b, so we should be OK as far as POSIX and
practical compatibility goes.
I don't know what other protocols or data formats use those abbreviations.
Internet RFC 5536 (Netnews Article Format) defers to RFC 5322 and so
also requires "EST" to mean -05.
But I'm not worried much about email or Usenet, as for many years the
RFCs have prohibited *generating* "EST", and required only *acceptance*
of "EST" meaning -05. I'm worried more about the many practical software
apps out there that use the equivalent of tzcode's tm_zone to *generate*
alphabetic abbreviations, and then use recognizers like this one:
https://github.com/postgres/postgres/blob/master/src/timezone/known_abbrevs.txt
... to hardwire "EST" as meaning -05. These recognizers work fine on RFC
5322 dates, as that RFC says "EST" must mean -05. But they would stop
working if TZDB changes "EST" to mean -04. Which means TZDB shouldn't do
that.
