[tz] [english 100%] Re: OpenJDK/CLDR/ICU/Joda issues with Ireland change

[Mark Davis ☕️]

> 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 at iana.org> wrote:

> On 28 Jan 2018, at 05:34, Robert Elz <kre at munnari.OZ.AU> wrote:
>
> > From: Meno Hochschild <mhochschild at gmx.de>
> > Message-ID: <15c91fab-ca48-d6bd-f961-2b7ce00e7b15 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20180128/485f0abe/attachment-0001.html>