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.