# [tz] What's "right"?

Michael H Deckers michael.h.deckers at googlemail.com
Sat Nov 14 20:23:42 UTC 2020

```    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.

```