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