[tz] What's "right"?
John Sauter
John_Sauter at systemeyescomputerstore.com
Sun Nov 15 14:46:12 UTC 2020
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/FEF0CB0CE755B4F67813AEC1E3596DEF/S0251107X0002023Xa.pdf/commission_31_time.pdf]
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 at systemeyescomputerstore.com)
--
PGP fingerprint E24A D25B E5FE 4914 A603 49EC 7030 3EA1 9A0B 511E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <http://mm.icann.org/pipermail/tz/attachments/20201115/915a5898/signature.asc>
More information about the tz
mailing list