[LEAPSECS] BBC radio Crowd Science

Warner Losh imp at bsdimp.com
Mon Feb 6 13:07:21 EST 2017

On Mon, Feb 6, 2017 at 10:58 AM, Zefram <zefram at fysh.org> wrote:
> Warner Losh wrote:
>>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
> The numbers are not on any time scale.  The numbers are derived from
> the time values, but are a different thing.

They are second labels which have different rules for TAI and UTC.

>>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.
> It does not lead to that conclusion in the general case.  (It does for
> the specific case of TAI-UTC changing from 0 s to 1 s.)  This is one of
> the options for handling TAI-UTC that I examined a few messages ago,
> and it leads to the conclusion that if TAI-UTC is initially positive
> then it increases some seconds *before* the leap second.

Actually it doesn't. I couldn't follow the logic on that argument at
all, so I didn't reply. At worst if you misapplied my method, you'd
get an off by one error.

> I'd examined it
> because it appeared to me that, by consistently using the irregular radix
> for subtraction, it was applying the principle that you were claiming to
> apply, though it leads to a different conclusion from the one you reached.
> (You responded that this was not your system.)

Yea, I've read through your message a couple of times and still don't
understand how you got to where you did.

> I'd still like to see from you a worked example of TAI-UTC for a time a
> few seconds before a positive leap second, where TAI has already ticked
> over into the following day, to compare against an equivalent example
> for a time inside the same positive leap second.  You've done a worked
> example inside a leap second, but not one in the preceding seconds.
> I want to see how you get a different result for 00:00:35-23:59:59 from
> that which you get for 00:00:36-23:59:60.

Sure. I still owe you that, and plan on giving you that. I'm a bit
crunched for time today since I've been working to get a release done
by noon today for the past week (for a problem that exploded into my
lap just after this thread started).

>>can't normalize N:23:59:60 to N+1:00:00:00 because in UTC they are two
>>different second labels.
> They certainly are different second labels, and in UTC they even
> label different seconds.  That's not in dispute.  I did not normalise
> one of them to the other.  The equivalence between them is only that
> certain relevant functions of UTC time labels, specifically MJD and its
> equivalents, yield the same value for both of these.  It is via those
> functions that TAI-UTC is tacitly defined.

When you convert to MJD, it appears you are assuming each day has
86400 seconds, which is why two seconds map to the same value.


More information about the LEAPSECS mailing list