[LEAPSECS] BBC radio Crowd Science

[Zefram]

Warner Losh wrote:
>Only for time_t computations.

The POSIX expression for time_t, if taken entirely literally, does the
same thing.  But that's not the only use of a scalar behaving in this way.

>              "reducing to a scalar value" unfortunately doesn't map
>1-1 onto UTC.

Right.  The scalar form does not adequately represent UTC.  Fully
representing a UTC time requires at minimum two parts: an integer
identifying the day and a continuous value identifying the time of day.
All uses of expressions that treat UTC as a scalar, such as "TAI - UTC"
and "UT1 - UTC", need to be interpreted carefully, with the understanding
that contextual information is required to perform a complete conversion.

>                                     TF.460 says nothing about this.

Indeed.  It makes some mention of TAI-UTC, but is not explicit about
the details of what that means.  It does say that it's always integral,
but doesn't say when it changes.  That is an unfortunate omission.

It is the common practice, in IERS documents and elsewhere, not a formal
standard, that establishes this usage.  One is also guided towards
this by its mathematical coherence, which of course is why it became
common practice.  Your way, doing the arithmetic in the irregular radix
implied by the sequence of UTC time labels, leads to more discontinuities.

Let's consider (again) the 2016-12-31 leap.  One second after the end of
the leap second we have (uncontroversially) UTC = 2017-01-01T00:00:01.0,
TAI = 2017-01-01T00:00:38.0, TAI-UTC = 37 s.  In the middle of the leap
second, 1.5 s earlier, we have UTC = 2016-12-31T23:59:60.5 and TAI
= 2017-01-01T00:00:36.5.  For you to derive TAI-UTC = 37 s as you do
essentially requires that we interpret that TAI label as if it were a UTC
label and ask how many seconds there are between these two UTC labels.
That's what using the irregular radix amounts to.  OK, that gets 37 s.
Now let's go back another 1.5 s, to a point one second before the
start of the leap second, and continue working that way.  We have UTC
= 2016-12-31T23:59:59.0, TAI = 2017-01-01T00:00:35.0.  The difference
between these two timestamps, taking account of the irregular radix,
is *still* 37 s, made up of 2 s from 23:59:59.0 to 00:00:00.0 plus 35
s from 00:00:00.0 to 00:00:35.0.

So in your system the discontinuity in TAI-UTC is not, as you
stated, at the beginning of the leap second.  Working backwards,
we find that TAI-UTC actually changed at 2016-12-31T23:59:24.0 UTC,
which is 2017-01-01T00:00:00.0 TAI.  At that instant we have (still
using the irregular radix) a 37 s difference in the time labels.
Half a second earlier we have UTC = 2016-12-31T23:59:23.5 and
TAI = 2016-12-31T23:59:59.5, with an uncontroversial difference
of 36 s.  Essentially, your system perceives UTC as a continuous
scalar, and perceives a discontinuity in *TAI*, where it jumps
from 2016-12-31T23:59:59.9 to 2017-01-01T00:00:00.0.  TAI omits
a second's worth of time labels supplied by the irregular radix,
2016-12-31T23:59:60.0 to 2016-12-31T23:59:60.9.

A negative leap is worse, because TAI takes on labels that don't exist
in the irregular radix.  How do you account for that?  If we permit
the out-of-radix :59, with its apparent numerical value, then we find
that the notional TAI scalar repeats a second's worth of values, with
out-of-radix notation being used to distinguish the two instances of
those scalar values.  Any computation that produces this TAI scalar in
its pure form cannot be used to unambiguously decode a TAI time.

Essentially, your irregular-radix system has the same problems for
which you deride the regular-radix system.  The difference between the
systems is in to which time scale they attribute the discontinuities
that arise in TAI-UTC.  Performing the computations using the regular
radix attributes them to UTC.  Using the irregular radix attributes the
discontinuities quite unfairly to TAI.

There's also a theoretical problem when TAI-UTC gets big enough to span
the time between two leap seconds.  Theoretical because UTC breaks down
in other ways before we can actually reach that.  But if it were to occur,
your irregular-radix arithmetic would see additional complexity.

To get the results that you stated, with TAI-UTC changing at the beginning
of the leap second, by using the irregular radix for the arithmetic,
actually requires that you use the irregular radix selectively.  You used
it for the conversion of times lying within the leap second, but not
for other times.  That's not a coherent system.

I think what you *actually* did in your head was more coherent than that,
but wasn't the use of the irregular radix that you claimed.  What you
did, and halfway described, was to treat 2016-12-31T23:59:60.5 as
2017-01-01T00:00:(-1).5.  You treated the leap second as being prepended
to 2017-01-01 rather than postpended to 2016-12-31.  In that scheme, the
notional UTC scalar, when computed as I have described using the regular
radix, does undergo discontinuity at the beginning of the leap second,
with the leap second duplicating the scalar values of the preceding
second.

-zefram