[LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 11:02 PM, Zefram <zefram at fysh.org> wrote:
> 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.

If it isn't in the standards documents, it's informal usage. While
useful in conversation, it can (and often does) lack the rigors
necessary to unambiguously implement the standard.

> 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.

I'd suggest that you re-read what I wrote, because these two
paragraphs do not represent that at all.

> 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.

For a negative leapsecond, it's clear that the offset changes at the
end of :58 second. Briefly, you are adding two to get the next second
instead of the customary one. In that case, it's clear that one comes
from the normal increment and the other one comes from decrementing
the TAI-UTC offset.

> 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.

My irregular-radix system? Nah, I can't take credit for what TF.460
promulgates it. I'm just doing regrouping within the different 'place
values' in the irregular radix to show when I believe the offset has
to change. The irregular radix math is no different than trying to
figure out what day will be in 47 days or was 47 days ago by counting
up and down months and the number of days when you hit an underflow or
overflow. So that would be Fed (1+47) or Feb 48 or March 48-28 or
March 20. People do this all the time, with various techniques, when
they borrow or carry in long hand base-10 arithmetic. It's much
simpler there because there are no weird irregularities to worry
about.

> 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.

Don't get me started on the inadequacies of leap seconds... The
mailing list archives are full of my rants there (though maybe people
understand the rants a bit more after this thread). But be that as it
may, I don't even know how to parse this. There's a problem in the
future well beyond the end of UTC that UTC doesn't take into account
is how it reads, which I'm not sure I can get excited about.

> 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.

You always use it. I even sent an example to the list for computing
deltas. The only time you need to take care is near a leap second,
because that's the only time the radix is irregular in the time-of-day
field (or put another way, when a minute has 61 seconds).

> 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.

Except I didn't. I started with a TAI time in 2017 and converted it to
a UTC time in 2016. Part of the conversion process did produce an
improper time, true. Which needed to be converted to a proper time,
but that's what happens when you have to do the radix math in steps
rather than have ADD, SUB or some other machine instruction do it for
you. It's part of the process. And debating whether that's appending
to last year or prepending to this year is beyond ridiculous. If I
doing 23-7 and grouping it as 10+(13-7) or as 2(-4) (meaning 20 + -4),
I'm not prepending 10 to the 20's or 20 to the 10's or anything else.
I'm just regrouping terms so I can produce an answer in normal form
using what's likely just a slightly off-beat notation that's
unfamiliar. That's what the business about the second field being -0.5
is about: just showing my work along the way to the answer. To take it
further to say it duplicates the previous second isn't really
supported since it will label the two seconds differently, as required
by TF.460. Unless, as I said in my previous reply, you convert to
time_t, which isn't an 1-1 onto mapping, which is an interesting
failing of time_t, but not in scope for this discussion about UTC
times which time_t can't unambiguously represent.

Warner