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. 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. I don't know how much software would break if we did that. > The only thing that is 100% certain are the offsets. Both the names and the > tm_isdst flag are moving targets and up to interpretation. CLDR already > spends a lot of effort on figuring out these common-use aspects, but makes it > clear that these are moving targets and for human display, not for protocol > usage. This does not seem to be so clear for the TZDB data. Presumably meaning "not so clear in the documentation for the TZDB data", perhaps with the addition "especially considering the fact that the TZDB data supplies alphabetic abbreviations for some timezones". Presumably the CLDR documentation "makes it clear that these are moving targets and for human display, not for protocol usage" in its documentation; perhaps the TZDB should do likewise. As for protocol use, August 1982's RFC 822 <https://datatracker.ietf.org/doc/html/rfc822> explicitly supported "North American" Eastern/Central/Mountain/Pacific time abbreviations. RFC 822 was obsoleted by April 2001's RFC 2822 <https://datatracker.ietf.org/doc/html/rfc2822>, whose section 4 "Obsolete Syntax" <https://datatracker.ietf.org/doc/html/rfc2822#section-4> relegates those to a "readers MUST handle this, writers MUST NOT generate this" status. October 2008's RFC 5822 <https://datatracker.ietf.org/doc/html/rfc5322> continues to do this. No support in the TZDB is required to implement the "readers MUST handle this" stuff - they can just hardcode EST, EDT, CST, CDT, MST, MDT, PST, and PDT in the parser. I don't know what other protocols or data formats use those abbreviations.
