On 2017-12-05 20:18, Russ Allbery wrote:
David Patte ₯ <dpatte@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