James Bellaire via tz <[email protected]> writes: > As long as downstream programs respect the change in the offset they > should not break. Downstream programs that for some reason hard code "EST" > as -05 instead of using tzData have created their own problems. This > change in this form was first proposed in 2018 so that has been plenty of > warning for downstream programs that EST could not always equal -05.
This is not to fundamentally disagree with anything you're saying, but there is a fascinating edge case here for software that has to deal with some obsolete file formats with historic dates. For example, software that needs to parse the obs-zone construction in the obsolete RFC 5322 syntax [1] (software that parses archives of old email or netnews articles, for instance) *does* have to hard-code EST as -05. [1] https://www.rfc-editor.org/info/rfc5322/#section-4.3 This will likely be straightforward given the most obvious ways to implement such old parsers, but this is a case where there is software in the wild that is correct to have hard-coded translations for the timezone abbreviations, since RFC 5322 itself defines the GMT offsets of those strings without regard for what current law might say. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
