[tz] What's "right"?
Michael H Deckers
michael.h.deckers at googlemail.com
Sun Nov 15 22:31:01 UTC 2020
On 2020-11-15 14:46, John Sauter wrote:
> 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". ..........
I am sorry; I should at least have included a
warning that this is mathematical lingo.
> ........ 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
> gdefinition, 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.
I think the view that different time scales are just relabelings
of the point of a time line is fundamentally flawed. I consider
a time scale to be the temporal part of a coordinate system for
4-dimensional spacetime; changing the coordinate system, even
if it is only for one coordinate, does not mean relabeling
the coordinate.
Yes, there are many people and several authors which
understand the term, time scale, in other meanings
(eg, ISO 8601). And a geological time scale is probably
not (yet?) part of a coordinate system.
At any rate, the values of (such) time scales are points on the
time line, which offers the well known operations (adding a time
value to a time point, determining the difference between two
time points, etc). These are operations on physical quantities,
and cannot be done with labels. Different time scales must take
their values on the same time line (at least when their values
are to be comparable).
Points on the time line can be denoted in many different ways:
with many calendars, many time units for time of day and time
since an epoch, and many different epochs for such counts; changing
a notation does not change the time scale anymore than an
elevation is changed by switching its notation from foot to meter.
When it is said that UTC is just TAI with the points on the
time line relabeled, this just means that the function from TAI
values to UTC values ("labels") is injective (ie, different values
of TAI are mapped to different labels). This is correct for a
suitable choice of leap second notations -- but it does not
tell us much about how UTC depends on TAI. In the the same
way, one could say that x³ is just a relabeling of x, but this
does not tell us how x³ depends on x, it doesn't allow
comparison of x³ with x, taking the derivative etc.
>> 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.
No, the IAU mean 2017-01-01 - 01 s, a negative value
for time of day.
Michael Deckers.
More information about the tz
mailing list