[tz] Leap Second Support Interval Field Request - RFC8536

[Michael H Deckers]

On 2019-12-06 21:45, Paul Eggert wrote:

> This won't have the desired effect. For example, it would cause the 
> Etc/TAI clock's adjacent ticks to be 1972-06-30 23:59:59 and 
> 1972-07-01 00:00:01, whereas the adjacent ticks should be 1972-06-30 
> 23:59:60 and 1972-07-01 00:00:00. Also, when compiling the Etc/TAI 
> zone with -L leapseconds, the resulting TZif file would have incorrect 
> transitions because each leap second would be applied twice.


      Oops -- I should not have omitted the time of day of
      the switches from the Zone lines -- sorry for the confusion.

      The complete lines must have a time of day, of course:

         Zone   Etc/TAI  0:00:10 - TAI   1972 Jul  1  0:00:00u
                         0:00:11 - TAI   1973 Jan  1  0:00:00u
                         ....
                         0:00:35 - TAI   2015 Jul  1  0:00:00u
                         0:00:36 - TAI   2017 Jan  1  0:00:00u
                         0:00:37 - TAI   2020 Jun 28  0:00:00u
                         0:00:37 - N_A

      So the "adjacent ticks" you mention are in fact
      the TAI values 1972-07-01T00:00:09 for UTC = 1972-06-30T23:59:59Z
                 and 1972-07-01T00:00:11 for UTC = 1972-07-01T00:00:00Z.
      Of course, these ticks of TAI are not adjacent: the TAI value
      1972-07-01T00:00:10 in between belongs to the leap second
      UTC = 1972-06-30T23:59:60Z.

      The Zone lines for right/Etc/TAI would give TAI as a function of
      TAI - 10 s, so they would get the constant STDOFF value 0:00:10.
      (And, yes, in this case the STDOFF value after 2020-06-28 is known.)

      That TAI can be considered as a tzdb "timezone" is an observation
      by Steve Allen, if I remember correctly.

      Michael Deckers.