[tz] What's "right"?

[John Sauter]

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/attachment.sig>