[tz] Reason for removal of several TZ abbreviations

[Brian Inglis]

On 2017-12-05 20:18, Russ Allbery wrote:
> David Patte ₯ <dpatte at relativedata.com> writes:
>> The original reason for the latest discussion was actually precipitaed from
>> a request of clarity into why Greenland time zone designator was changed
>> from WGT/WGST to -3. The original author said that he felt WGT/WGST was in
>> common usage.
> I think the abbreviations are a much different issue than the zone 
> identifiers, and I'd personally love to see them go away completely (even 
> ones like PDT).
> 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! ;^>

Assumptions about the importance to users of these historical artifacts, and
bikeshed arguments about "compatibility" often prevail, when the appropriate
input should be - it was made up and has been dropped - how much can you afford
to pay to keep it around?

People have compiled and used calendars for millenia, Gregorian calendars for
over 250/400 years, standard time zones for over a century, summer daylight
saving times for about a century, leap seconds for 45 years, and programmers
still get simple things badly wrong, that could be easily tested and checked
using suitable APIs or apps on the same system, or many other systems.

The C and POSIX standards should have defined an opaque temporal type with
access only via the API, and later an opaque calendrical type and API, perhaps
optional, to extend this on hosted implementations.
It's a benefit that tz handling is effectively opaque to most programmers.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada