[tz] zic bug: Wall-clock ordering of transition times

Brian Park brian at xparks.net
Tue Dec 29 21:32:29 UTC 2020

Is there a known special problem for Europe/Kaliningrad? My code and the
HowardHinnant date library agree on this transition. The TZ database says:

Zone Europe/Kaliningrad
 3:00   Russia  MSK/MSD 1989 Mar 26  2:00s
 2:00   Russia  EE%sT   2011 Mar 27  2:00s
Rule    Russia  1984    1995    -       Sep     lastSun  2:00s  0       -

Rule    Russia  1985    2010    -       Mar     lastSun  2:00s  1:00    S

So, on Mar 26, 1989:
* at 1:59, Kaliningrad is on UTC+3 (SAVE=0)
* at 2:00s (which is identical to 'w' in this case, because we need to use
the STDOFF of the transition immediately to the left), Kaliningrad switches
to UTC+2+{SAVE}
* but the Russia rule also takes effect at 2:00s, so SAVE becomes +1
* so Kaliningrad switches to UTC+2+1, i.e. remains at UTC+3
* Kaliningrad clock stays at 2:00

I think the key here is that both the Zone entry and the Rule entry use the
same "2:00s", which are both interpreted using the STDOFF of the transition
immediately to the left of the 2:00s.

I don't know the internal details of the HowardHinnant's date library, but
my code normalizes the various transition times to 'w' time, so the above
explanation is only a rough translation of what the code actually does. The
other interesting question is what happens on Sept 24, 1989, when it
reverts back to STD time at 2:00s. Both my code and HowardHinnant date
library seem to correctly convert the 2:00s to 3:00w, and the clock goes
from 2:59 -> 2:00.


On Tue, Dec 29, 2020 at 11:58 AM Michael H Deckers <
michael.h.deckers at googlemail.com> wrote:

>     On 2020-12-29 19:55, Michael H Deckers wrote:
> > 1991 Mar 31  2:00s
> >
>     instead of 1989 Mar 26  2:00s
>     Sorry.
>     Michael Deckers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20201229/6e82da4f/attachment.htm>

More information about the tz mailing list