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

Robert Elz kre at munnari.OZ.AU
Sun Jan 28 05:34:14 UTC 2018

  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.

  | 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

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.


More information about the tz mailing list