[tz] Reason for removal of several TZ abbreviations

[Lester Caine]

On 06/12/17 07:13, Russ Allbery wrote:
>> 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.

Current discussions on better support for timezones tend to fall at the
first hurdle by complaining that some database values do not support it
properly and EXPECT inclusion of the OFFSET in some way as the fix! So
much more work needs to be done to promote the differences between
simple offsets - however displayed - and the real identification of a
clients timezone. I'll say yet again, the crude provision of an offset
in the browser header as an abbreviation or even a simple number and
trying to infer from that the relevant timezone is the main legacy
problem. timezone_id is such a critical part of this process that the
fact tzdist does not nail down even tzdb as a clean standard source is
not taking things in the right direction, but using long strings as an
id is equally troublesome when their content is only really valid in a
small number of countries of the world? This is what makes abbreviations
something internationalization tends to mistakenly rely on?

This is where the geonames approach of defining a numeric id for every
name in the world works so much better as systems can pick out their
preferred language to display the result. My own method of normalizing
historic timestamps is to only store UTC times, so I don't want the
database to magically convert some arbitrary offset! The location of the
event is much more important that 'somewhere in Europe' and in a large
number of cases you need no more than the location with a UTC time ...
if only we have a TZ database we could rely on for the information at
the DATE of the event ;)

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk