[LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Mon, Feb 6, 2017 at 6:39 AM, Zefram <zefram at fysh.org> wrote:
> Warner Losh wrote:
>>So either there's some weird math that lets one subtract two numbers
>>that are different and get 0 as the answer, or the delta has to change
>>at the start.
>
> To the extent that they're different, the things being subtracted are
> not numbers.  The expression "TAI - UTC" is shorthand for something more
> complicated than a numeric subtraction, which will nevertheless produce
> a numeric result.  The linear reduction of a timestamp that Clive and
> I have separately described is sufficiently numerical to admit of a
> straightforward subtraction, and the linear reductions of N:23:59:60 and
> (N+1):00:00:00 are duly the same.

Saying that the two numbers are the same is improper. Or rather, it
depends on which time scale you are looking at them in if they are
improper. In UTC they are clearly not the same, but different second
labels. UTC can express this non-sameness. TAI can't do that, so you
have to reduce the improper time to a proper one before you can
compare them. There's two ways to look at it: convert them both to TAI
or convert them both to UTC.

So, if you look at the two times in TAI land, you have to do that
folding of seconds that's implicit in the linearization formula. If
you do that folding of seconds, then the 60 in the irregular radix
takes care of the difference in the first second since you've folded
its value to the value of the first second of the next day. That means
you have to say the difference starts after the leap second.

However, if you look at the two times in UTC land and compute a delta
in UTA land, then you find the interval between N:23:59:60 and
N+1:00:00:00 you wind up with 1 second. That leads to the conclusion
that the difference starts at the beginning of the leap second.

The whole discussion about when the difference starts can be boiled
down to that. What's the proper way to look at it? Depends on how you
do the math to do the conversion to when you use the new offset.

> An analogy: suppose we do a bit of arithmetic in hexadecimal.  We can
> all agree that 0x5a0 - 0x5a0 = 0x0.  Suppose that while keeping the
> hexadecimal radix we additionally use the digit "g", with value sixteen.
> Now we find that 0x5a0 - 0x59g = 0x0.  The difference is zero, yet the
> numbers appear different.  What's going on?  Well, the numbers per se
> are the same: 0x5a0 = 0x59g is a single numerical value.  The things
> that are different are the digit sequences "5a0" and "59g", which under
> the convention being used here are two different ways of expressing that
> single number.  The digit sequences are not themselves numbers.

I think now you're getting confused about irregular radix. If we were
to do that with hex, the number 0x59g would be a non-normalized number
that normalizes to 5a0 because hexadecimal is a regular radix. You
can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two
different second labels.

Put another way: it's indisputable that if I have one event at
N:23:59:60.1 and a second event at N+1:00:00:00.6, they happened 1.5s
apart.

Also, I'll note that bulletin C says from 0h, which is a time
expressed to only one significant digit. They chose to not use the
unambiguous 00:00:00 opting for the less precise 0h. If you make the
second folding argument via time linearization, you map both the leap
second and the first second of the next day to the same value. Which
one of those is 0h?

I think the final answer is: It's ambiguous and I was wrong to insist
that there's one true way to recon it.

Warner