On Sun, 2020-11-15 at 10:51 +0000, Michael H Deckers wrote:
Neither the function that maps UTC to Pacific time nor the function defined by the IERS that maps UTC to a corresponding value of TAI are surjective, and the interface has to tell that. In that sense, the cases are similar.
I had to look up "surjective"; I thought at first it was a typo for "subjective". If I am understanding that word correctly, I think I must be defining the domains of Pacific Time, UTC and TAI differently than you do. I regard those domains as containing only labels for instants of time. Thus, 2018-03-08T02:30 is not a member of the Pacific Time domain since it does not label an instant of time. By my definition, every Pacific Time label corresponds to a UTC label, and all UTC labels have a corresponding Pacific Time label, and thus the mapping is surjective. Similarly, every second has both a UTC label and a TAI label, so the function that maps UTC to TAI is surjective. To take an extreme example for purposes of illustration, the label 2020-11-15T99:99:99Z is not a member of the UTC domain, since there is no second with this label, so converting it to Pacific Time or TAI does not make sense.
The leap second notation is only applicable with notations with enough redundancy, it is not the only possible notation indicating a leaps in UTC, and it does not work for UTC <= 1972. Nor does it help if the user wants to determine TAI - UTC for a given value of TAI.
I regard TAI and UTC as collections of labels rather than numbers, so TAI - UTC is not meaningful unless you convert both to numbers. The result of the subtraction will depend on how you map the labels onto numbers.
Another notation for leaps in UTC was recommended by the IAU in 1970: 9.4. The time of an event given in the old scale, before the leap second, will be given as a date in the previous month, exceeding 24h if necessary. The time of an event given in the scale after the step will be given as a date in the new month, with a negative time, if necessary. Resolution adopted by the 14th General Assembly of the IAU in 1970, online at [https://www.cambridge.org/core/services/aop-cambridge-core/content/view/FEF0...]
So the alternative notation for 2016-12-31T23:59:60Z would be 2016-12- 31T24:00:00Z. That looks strange to modern eyes, but I don't think it is any worse than extending the minute. Other possibilities are to extend the hour: 2016-21-31T23:60:00Z, the month: 2016-12-32T00:00:00Z, or the year: 2016-13-01T00:00:00Z. John Sauter (John_Sauter@systemeyescomputerstore.com) -- PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E