[tz] Reason for removal of several TZ abbreviations

[Russ Allbery]

Brian Inglis <Brian.Inglis at 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 at eyrie.org)              <http://www.eyrie.org/~eagle/>