From: Meno Hochschild <mhochschild@gmx.de> Message-ID: <15c91fab-ca48-d6bd-f961-2b7ce00e7b15@gmx.de> Date: Sat, 27 Jan 2018 21:49:27 +0100 Subject: Re: [tz] [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with Ireland change | About the wish for the restriction that a set of rule lines with same | name should not have mixed signs of dst offsets, I will try to explain. | The whole thing is about labelling what the zero dst offset stands for. The issue is that it does not (by itself) "stand for" anything. This is one of the (invalid) assumptions that people tend to make, probably because it has mostly seemed to be universally true in (most of) the US, and in Europe, and yes, in Australia, and of course in those places that have only ever had one zone offset since standardised time was adopted. But jurisdictions are free to (without implementing any kind of annual time shift, ala summer time or daylight savings) alter their timezone (that is, shift their clocks relative to UTC) any time they like, as often as they like, and to anything they like, and can alter the name they call their time (assuming that it is called anything other than "the time") any time they like as well (either at the same time as a change of offset occurs, or just at some random time for whatever reason appeals.). There is simply no one name, or UTC offset, for "standard" or "alternate" time in any timezone - attempting to force one is simply wrong. | If such a set of rule lines only contains either positive or zero SAVE | then the zero dst offset corresponds to winter time (default). If the | set of rules only contains negative or zero SAVE then the zero dst | offset corresponds to summer time (Eire). It one could assume that the world was nice and simple as that suggests, then that might work - but it isn't. What will you do when some country (other than Eire which is already sane, it seems) decides that it is really crazy for the "standard" time to only apply 5 months (approx) of the year, and for the other time (daylight savings or summer time, or whatever it is called locally) to operate for the other 7 months, and redefine standard time to be the longer period, and the other time (probably with a different name, perhaps winter time) to the shorter period. Then we have from 19xx (whenever summer time was introduced first, or 1970 or 1990 if there is an epoch we do not consider before) until 2020 we have standard time offset = NN00 and summer time MM00 (where MM is NN+1 probably) and after 2020 we have standard time is MM00 and winter time is NN00. That is 1 hour positive DST until 2020 and 1 hour negative after that. And what if winter time after 2020 is offset PP00 where PP == NN - 1, or perhaps that change only happens in 2023, or perhaps differently, that becomes "mid-winter" time and only applies for 1 month in the middle of winter with normal winter time applying for the other 4 cooler/cold months (2 either side of mid winter time). Everyone needs to plan to cope with things like this - before some legislature decides to specify it. | By the way, I don't mind if my suggestion of introducing an optional | META column at the end of a rule line might be modified ... I have no problem with that - though a "meta" column that can contain almost any random extra data might be a bit much. I think something that provided a better linkage to CLDR than what we now have would be a good idea. But CLDR (and its clients) need to accept that doing that will mean altering they way they work - no more assumptions that there are just two "kinds" of time in one zone, no assumptions about relative offsets, of that standard time has some constant offset from UTC. All of that has to go. How the implementation happens is really better discussed after a suitable API is agreed. That is whether the new data goes in the zoneinfo files, or elsewhere - the former would make more sense, for most zones there will not be a lot of it, all it really needs is a short int index in each ttinfo, and yet another list of strings). These could probably even be included with the list of zone name abbreviation strings. Similarly what the tzdb src file format would look like. | And even then I would prefer not to have mixed signs | within the same set of rules equally named. It makes programming much | easier. If you are doing any programming at all where it matters, you are programming the wrong thing (except possibly for uses like dumping a timezone like zdump does, but with the internationalised names included). Other that semi-diagnostic (and just "explain how wacky things are to people") uses, code should never care. If it does, it is almost certainly assuming something that is not correct. kre