As Robert Elz says, almost anything is possible.
True, but you can't design software and data to handle everything. Some government could decide that every other day the clock is to move forward by the number of minutes in that day of each Hindi month. Doesn't mean that we should design for that now. The TZDB group has done a masterful job over the years, and we all owe a debt of gratitude to all of the people who have spent so much time on it. But like many, many systems, its very success puts constraints on it. There are so many changes I wish we could make in Unicode, for example, but even if "formally speaking" we could make those changes, practically speaking they would be massively disruptive. Clearly sometimes you have to make disruptive changes, but any such change should have very, very clear ROI that strongly outweighs the disruption. The change to negative offsets is massively disruptive, and has no significant functional difference I can see; functionally it is purely the TZDB abbreviations. The TZDB should not concern itself with names, since they always have to be localized for mere humans. So frankly, I see no reasons for ever having SAVE<0. But let's suppose that there are. In that case, I see no option other than issuing both data files that are strictly SAVE≥0 and data file(s) that no such restriction (or the logical equivalent to dual files) until such time as we have confidence that the number of clients broken by this change becomes very small. === In the meantime, let me try to set out some of the things that CLDR does and doesn't do, since people have questions about that. Some is a recap of what others have said. The architecture is built to supply a variety of different kinds of names for timezones, in all of our languages, to try to meet local expectations. It does not do calculations of time offsets; it depends on clients using the tzdb for that. The linkage is supplied by the tzid (eg America/Los_Angeles). (As has been seen in these threads, the clients do the calculations in very different ways, and are updated on very different schedules. It is quite customary in some clients for the tzdb to be updated regularly, but use an old version of code and and old version CLDR data.) Some of the following is a simplified description, in cases where I think the complications are not particularly relevant. - CLDR is targeted at names in locales: by language, sometimes also different by script (where multiple scripts are common for the language), sometimes also different by country (where there are local differences). - There are multiple kinds of names based on input parameters, with a fallback mechanism if a name is missing. Worst case, you get an offset from GMT/UTC (localized, eg "ጂ ኤም ቲ-0300") - For a given locale, the names must be unambiguous. For example, the term X can't be used *in the same locale, in the same timespan *as a name for both a tzid with UTC+3 and a tzid with UTC-6. - *metazones:* these provide a mechanism for sharing names across tzids. - Logically the lookup is roughly: <tzid> → name; if name = ∅, then <datetime, tzid> → metazone → name - The same tzid can be in different metazones over time. - For some more details, see below. - *abbreviated: *we support abbreviations, but only supply abbreviations for a locale if they would be both customary and unambigous in the target locale (often different by country). - *generic:* - id="generic" is most used for a recurring events. "Every Thursday in 2018 at 14:00 Pacific Time", referring to wall time in the metazone America_Pacific. - *summer vs winter* - id="standard" is the ID used for SAVE=0. - id="daylight" is the ID used for SAVE>0. Only present where the metazone/tzid has such a contrast. - These are just IDs, the names will be in different languages, and can be /winter/ and /summer/, or something else: whatever makes the most sense to users of that locale. For example, for English, we have daylight → "Irish Standard Time" - There is a current restriction to 2 fields. It would be relatively easy for us to add an additional field, which we would do if some modern locale had something like "double-daylight" time. It might take a long time for clients to support that, however. *Metazones* These provide a level of indirection. "America_Pacific" is a metazone that is currently shared by "America/Tijuana", "America/Vancouver", ... The mapping depends on a date-time span + tzid. For example: <timezone type="America/Bahia_Banderas"> <usesMetazone to="1970-01-01 08:00" mzone="America_Pacific"/> <usesMetazone to="2010-04-04 09:00" from="1970-01-01 08:00" mzone="America_Mountain"/> <usesMetazone from="2010-04-04 09:00" mzone="America_Central"/> </timezone> When a name is looked up, we first lookup by tzid, then by metazone. So for a given loc, a particular tzid's names can be overridden to be different from the shared metazone's names. Mark On Sun, Jan 28, 2018 at 4:06 AM, Peter Ilieve via tz <tz@iana.org> wrote:
On 28 Jan 2018, at 05:34, Robert Elz <kre@munnari.OZ.AU> wrote:
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.
This isn’t just some theoretical possibility either. In Europe, with its reasonably stable rules, Portugal has changed timezone twice within my memory: in 1992 and 1996. Looking at the tz data, it has changed twice more in my lifetime: in 1966 and 1976. For the earlier two changes the clocks changed and the isdst flag didn’t (Portugal didn’t do DST then). For the later two the clocks didn’t change but the isdst flag did.
As Robert Elz says, almost anything is possible.
Peter Ilieve