Brian Inglis <Brian.Inglis@SystematicSw.ab.ca> writes:
On 2017-12-05 20:18, Russ Allbery wrote:
I know that's too radical to be practical, but those three or four character abbreviations are traps for the unwary. There aren't enough places to put disclaimers about them, people constantly assume they're unique when they're not, and I've found far, far too many buggy date parsers that try to extract meaning from them. Replacing as many of them as possible with simple offset indications or some other mostly meaningless string is a service to future programmers as far as I'm concerned.
Just you wait to see what they come up with to generate the previous output! ;^>
Thankfully, we're well down the path of deprecating them in output. RFC 2822 marked all use of time zone abbreviations in Date headers obsolete in email (later adopted in Netnews as well by RFC 5536). ISO 8601 specifies using zone offsets, not abbreviations, and is increasingly widely adopted. strftime() is now far, far more common in new code that I see than ctime() and similar APIs. We're always going to be stuck with them in legacy files and code that has to parse old data, but we *can* push them slowly out of our software. I've been very pleased to see that dropping the more obscure and invented abbreviations has mostly broken test suites, not real code, at least from reports here. I haven't seen a legitimate reason to parse any time zone abbreviations other than the US ones (which were hard-coded in RFC 822) in quite some time, other than in a few archival applications handling very old files and formats. -- Russ Allbery (eagle@eyrie.org) <http://www.eyrie.org/~eagle/>