[tz] What's "right"?

[Michael H Deckers]

    On 2020-11-13 22:51, Guy Harris wrote:
> On Nov 13, 2020, at 5:17 AM, Michael H Deckers <michael.h.deckers at googlemail.com> wrote:

>>     The definition of UTC states that the offset UTC - TAI is a piecewise
>>     constant function of TAI (for TAI >= 1972-01-01 + 10 s).
> As I understand it, in that statement, neither TAI nor UTC are expressed as a count of seconds since some epoch, with
> the delta being between those two counts.

     The definition of a time scale, and the difference of two time scales,
     is independent of the units used to express values of time or of a
     time scale. Values of every time scale can be expressed as seconds
     since some arbitrarily chosen epoch, such as Julian date (as days since
     the Gregorian date -4713-11-25 + 12 h), as MJD or as a date expressed
     in some calendar date plus a time of day expressed in one or more time
     units. It's like a temperature that does not change when you express
     it in °C or °F instead of K.

>    the delta being between those two counts.  It means, for example, that:...
> 	June 30, 1972, 23:59:60 UTC is July 1, 1972, 00:00:10 TAI; (the June 30, 1972 leap second)


     The notation "1972-06-30T23:59:60" for a UTC value is a shorthand
     for: "the UTC value at the instant when TAI is 1972-07-01T00:00:10".
     That UTC value obviously would be 1972-07-01T00:00:00 if TAI - UTC
     were 10 s at that instant; and it would be 1972-06-30T23:59:59
     if TAI - UTC were 11 s at that instant; the IERS just does not specify
     which value of TAI - UTC applies at that instant.


> The computing interfaces, with the "posix" values, allow for the conversion of a value expressed as POSIX "seconds since the Epoch" - i.e., as a count of seconds, *excluding* leap seconds, that have elapsed since the Epoch - to a date and time, expressed as year/month/day/hour/minute/second, either as UTC (gmtime()) or as local time in any tzdb region (localtime()).


     I prefer to say "TAI -  X expressed in seconds" and "UTC - X
     expressed in seconds" because the recipe for not counting a
     negative leap second in the "count of seconds except leap
     seconds since X" is quite misleading.


>>     The converse conversion, from a datetime of a tzdb Zone time scale
>>     to a corresponding datetime of UTC for the same instant,

>>     is not so
>>     well defined since there may be no such corresponding datetime of
>>     UTC, or there may be two such.
> Yes, but that has to do with daylight saving time/summer time, *not* leap seconds.


     This year, at the instant when UTC was 2020-03-08T10Z,
     Pacific time jumped from 2010-03-08T02 to 2010-03-08T03,
     and when UTC was 2017-01-01T00Z, TAI jumped from
     2017-01-01T00:00:36 to 2017-01-01T00:00:37, as the IERS
     tells us. Since the rates of UTC, Pacific time and TAI
     are the same, the question, what was UTC when Pacific time
     was 2010-03-08T02:30, is exactly similar to the question
     what was UTC when TAI was 2017-01-01T00:00:36.5.

     Michael Deckers.