> 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.