On 2020-11-13 22:51, Guy Harris wrote:
On Nov 13, 2020, at 5:17 AM, Michael H Deckers <michael.h.deckers@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.