On 2018-07-11 07:58, John Wilcock wrote:
Le 11/07/2018 à 14:39, Robert Elz a écrit :
TZ doesn't care really, so that's not an issue.
However there is lots of other code which believes it sane to parse the zone acronym and draw conclusions from it (that is, if "CET" appears, it must mean UTC+01 and if CEST is there, it must mean UTC+02). That's horribly unreliable, and should be squashed. But it is more widespread than you'd think.
Oracle DBs and Java appear to use those ids in lieu of sensible time zone ids, and PostGres SQL ignores changes that don't fit their standard legacy model. POSIX still does not support e.g. Irish Standard Time properly, nor this project's time zones.
No doubt - but I would venture to suggest that this is comparable to pre-Y2K code that believed two-digit years were sane! Thankfully, code that used such logic was indeed squashed when the assumption was proven invalid :-)
The existence of such code is not a sound basis, IMO, for adding a recommendation to refrain from changing the meaning of the current abbreviations (though admittedly it can do no harm to point out that such code does exist).
Changing the meaning of time zone name and abbreviation definitions that existed prior to computers, and ignoring that many systems may not be changed to reflect any changes the EU committees come up with, whenever they get around to that, is not a sound basis for making such a change. All historical references prior to the change will have different meanings than the new convention, and all references in legislation will have to be changed, so adoption by countries may be staggered, depending on whether they have to areas that observe time in other zones for economic reasons. This project documents which legislated time is adopted where and when.
One might even hope that a change of this nature affecting a major world region such as the EU would result in a Y2K-like trigger to clean up code that handles time zones...
Vendors would have to rearchitect their systems to handle time zones as documented in this project: if customers are not going to spend money with them for better time zone support, they will not even look at the impact. I don't see any schedule or timetable anywhere, which means vendors will assume no changes will be agreed, and won't waste time on it, until legislative changes are made with sufficiently long lead time. Otherwise, they will document and publish a workaround, and maybe add the work to the end of the queue, for the interns to handle. Multiple occurrences per year of problems have not convinced vendors to fix their legacy practices, so they either ignore the change and suggest workarounds (if you are in CET, select EET), or leave it to downstream app developers to deal with. This project leaves it to the downstream platform or distro suppliers to deal with. -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada