On 2020-11-14 20:48, John Sauter wrote:
On Sat, 2020-11-14 at 20:23 +0000, Michael H Deckers via tz wrote:
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.
Since 2017-01-01T00:00:36.5 TAI is a valid time, and UTC has a name for every second, there must be a corresponding UTC time. If I have done my arithmetic correctly, that time is 2016-12-31T23:59:60.5 UTC.
This is not the same as asking for the UTC corresponding to 2010-03- 08T02:30 Pacific time, because that is not a valid time. That is, there is no point in time with that name. John Sauter (John_Sauter@systemeyescomputerstore.com)
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. 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. 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/FEF0CB0CE755B4F67813AEC1E3596DEF/S0251107X0002023Xa.pdf/commission_31_time.pdf] Michael Deckers.