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

[Michael H Deckers]

    On 2020-12-05 19:45, Tim Parenti wrote:

> It appears that this bug also manifests in other cases where the strict
> ordering of transitions does not exactly match the strict ordering of
> wall-clock times: Trying out "2:30" in the UNTIL field should mean that the
> Zone transition should happen 30 minutes BEFORE the US Rule would take
> effect (and thus require two transitions), but by wall-clock time, it would
> "appear" to be 30 minutes AFTER (fooling zic into thinking only the
> "latter" Zone transition is needed as the Rule would have "already" taken
> effect).  And, indeed, the results are similarly incorrect here, too:
>
> --- to2050.tzs 2020-12-05 14:11:12.000000000 -0500
> +++ to2050new.tzs 2020-12-05 14:36:07.000000000 -0500
> @@ -5201,7 +5201,7 @@
>   2014-03-09 03 -04 EDT 1
>   2014-11-02 01 -05 EST
>   2015-03-08 03 -04 AST
> -2018-03-11 03 -04 EDT 1
> +2018-03-11 02:30 -04 EDT 1
>   2018-11-04 01 -05 EST
>   2019-03-10 03 -04 EDT 1
>   2019-11-03 01 -05 EST
>
> Certainly an edge case in this particular instance, but given that many
> historical transitions coincide tightly with transitions in other regions
> being "joined" or "left", perhaps one worth a further look.



     Wow!

     I do not think that this is a bug. It could be the rule that governs
     the cases where the change specified by two successive Zone lines Z₁
     followed by Z₂ does not cause a switch to the time scale as specified
     by the STDOFF of Z₂ plus the SAVE value as specified with the
     RULE of Z₂ (as one would expect).

     That such cases exist is well-known; one example is the jump in
            America/Juneau  near 1980-04-27
     that uses YDT = UTC - 08 h starting at 1980-04-27T10Z, one hour
     before YDT starts to be used according to the US Rules. I do not
     have a complete list of these cases, nor do I know whether the
     following precisely formulated rule, as suggested by the examples
     you describe, would explain all these cases.

     Let X be the instant designated by the UNTIL field of Z₁; namely, the
     first instant at which the time scale UTC or UTC + F of UTC + F + S,
     (depending on the explicit of implicit suffix u, s, or w in the
     UNTIL field of Z₁) assumes a value >= the datetime indicated in the
     UNTIL field of Z₁, where F is the value of the STDOFF of Z₁ and
     S is the SAVE value last set strictly before the instant X.

     Then such a case would occur if the following two conditions apply:
     • the RULE field of Z₂ names a Rule that does not contain a Rule line
       applicable (in the context of the STDOFF of Z₂) at the instant X but
       that does contain a Rule line applicable at an instant Y next
       after X, and that Rule line specifies an increase in the SAVE value
       by an amount B > 0 h;
     • the instant Y is at most B after X (that is, UTC(Y) - UTC(X) <= B)
       and Y is strictly before the instant designated by the UNTIL field
       of Z₂.
     Under these conditions, the SAVE value used for the instants on
     or after X, and strictly before Y is the one that is set only later at
     the instant Y (and which is greater by B than the SAVE value
     described by the Rule of Z₂ for the instants in [X..Y[).
     Probably, also the LETTER value and the dst bit as set at Y also
     apply to the instants in [X..Y[.

     I find it a bit embarrassing that the precise semantics of zic input
     is only known to C compilers, but I have to admit that I am currently
     not seduced by the prospect of wading through C code maintained since
     1980 or so, with lots of macros.

     Regarding the wording of the ordinance:
     • it is not unambiguously evident which time scale is used for
       interpreting the expression "come into operation at 2:00 a.m.
       on 11th March 2018"; it could be the time scale used earlier
       (as often used in tzdb) or the one used afterward;
     • that the time scale "as the Eastern United States of America"
       does not assume the value 2018-03-11T02:00 is an interpretation
       that assumes that this time scale is right continuous (as a
       function of UTC). That civil time scales are right continuous
       is an assumption that is supported by the general method of
       adjustment with the help of time signals (and valid for UTC
       as a function of TAI) but it is nowhere stated explicitly
       in any legal text, as far as I know.
    The text of the ordinance is consistent if one assumes that the
    time of the switch is given in EST and EST/EDT as well as the
    time scale of Grand Turk is assumed to be left continuous when
    UTC is 2018-03-11T07Z.

    Michael Deckers.