[tz] EU Public Consultation on summertime arrangements

[Brian Inglis]

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