[LEAPSECS] BBC radio Crowd Science

[Warner Losh]

On Tue, Jan 31, 2017 at 2:20 PM, Brooks Harris <brooks at edlmax.com> wrote:
>> It's the only way to encode one number such that the irregular radix
>> math works out.
>
> I think I'm going to need an example I can work through to fully understand
> you here. When you get a chance, or can point me to something, thanks.

OK.

>>
>> And treating a positive leap second 'special' that
>> needs an extra decrement is isomorphic to changing the delta at the
>> start of the second.
>
> Ah, well the Leap Second is special, isn't it, even from the point of view
> of your "irregular radix
> math"? You are detecting it by whatever means and then treating it as if the
> TAI-UTC value incremented and the start of the Leap Second so its convenient
> to your methods, right? I mean, how its detected and treated could be seen
> as an internal implementation choice.
>
> My "IsLeapSecond" flag can also be generated internally so long as there is
> adequate metadata, either a IsLeapSecond or IsLeapSecondMinute, or
> IsLeapSecondDay or something. But in any case you still need the TAI-UTC
> value.
>
> The simple TAIToUTCDemoConsole program is not exactly how I do it in more
> elaborate code, but, generally I aim to do everything with integer math and
> logic.
>
> I wrote the little program to illustrate the resulting values, especially
> the UTC seconds value, to explain what I meant by the YMDhms(TAI) and
> YMDhms(UTC) and to stimulate just this convrsaion, thanks.
>
> I've found the IsLeapSecond flag to be very helpful metadata, especially
> when a receiver of a timestamp is interpreting it. If its explicitly flagged
> it saves any processing to detect it.

I'm saying that the extra "is it a leap second" bit is a complication
that's not needed for the computation. The fact that it may be useful
for other things isn't really relevant.

Let's take the TAI time 2017-01-01T00:00:36.5. Now, this is, as you
know, the leap second. To compute what value this is, we take the new
offset (37s) and subtract it, giving the following unreduced answer:

2017-01-01T00:00:(36.5-37)
2017-01-01T00:00:-0.5

which we computed simply by subtracting 37 from the seconds field.
We've not yet renormalized the notation. That's where the irregular
radix stuff comes in. So, to normalize, we need to borrow one from the
minutes column. To do that, we need to borrow one from the hours and
so on. The minute we are borrowing from has 61 seconds, so we can
rewrite this as

2016-12-31T23:59:(61-0.5)
2016-12-31T23.59:60.5

which is the correct answer. We need only know the size of the minute
we are borrowing from to make the computation.

This is the same math, btw, you'd use to find an interval entirely
inside UTC. What's the time difference between 2017-01-01T00:00:01 and
2016-12-31T23:59:58? The answer is 4. We can get this two ways. First,
we can do it the tedious way of counting:

23:59:58
23:59:59 1s
23:59:60 2s
00:00:00 3s
00:00:01 4s --> Answer

We can also do it by subtracting the two times:

 2017-01-01T00:00:01-2016-12-31T23:59:58

First step is to borrow from the previous minute, which rewrites it as

2016-12-31T23:59:(61+1)-2016-12031T23:59:58
2016-12-31T23:59:62-2016-12031T23:59:58
proceeding to the subtraction, term by term, we get 00:00:04.

In both cases, we did need to know that 23:59 had 61 seconds, but we
didn't need to have a special leap second flag associated with any of
the timestamps for the math to work out right. Knowing that it has 61
seconds sometimes is exactly the same thing as knowing that sometimes
February has 29 days some years. The only difference is that one is a
math formula for thousands of years, and the other is a table lookup.

> I'm not sure of that. It seems to me you are viewing it through a "irregular
> radix math" lens, which I'm sure isn't bad, but its not the only approach.

Sure, you can do it some crazy way that maps to how the numbers are
counted, but is more complicated. My entire criticism of your approach
boils down to "it's more complicated to separate out isALeap stuff"
since as I've conceded, the two methods are isomorphic since the +1
that's needed on the offset with your method is added specially. It's
on that basis that I say without equivocation the offset changes at
the start of the leap second.

>> How you encode your internal tables is
>> up to you, so long as they are isomorphic to what I'm saying.
>
> Yes, I agree, any implementation could do it whatever way appropriate, but
> I'm not sure about the TAI-UTC update topic yet.
>
> I'll bet we're getting the same results, at least as far as TAI
> seconds-to-YMDhms(UTC) is concerned. If we're not there's an interoperabiliy
> problem. Of course testing and verifying timekeeping algorithms is tedious.
> But maybe we could make up a couple test examples and give generating a few
> listings a go?

If we get the same answer, we get the same answer. There's no
interoperability issue. If your answers differ from mine, at least one
of us is doing wrong. However, the internal representation is likely
not too interesting.

Warner