[LEAPSECS] BBC radio Crowd Science

[Zefram]

Warner Losh wrote:
>Actually it doesn't. I couldn't follow the logic on that argument at
>all,

Let me see if I can work through it more clearly, and more in the
terminology that you have used.  The first case below is one that you
have addressed in detail; the others are what I derive from it using
what seems to be the same method.

At the beginning of the leap second, we have 2017-01-01T00:00:36 TAI
corresponding to 2016-12-31T23:59:60 UTC.  To compute TAI-UTC we need
to subtract 2016-12-31T23:59:60 from 2017-01-01T00:00:36.  These time
labels are clearly in consecutive minutes; the subtraction is of the form
(N+1):36 - N:60.  Finding that in the seconds position the subtrahend
is larger than the minuend, we must borrow from the minutes position.
We know that the minute in question has 61 seconds, so borrowing the one
minute amounts to borrowing 61 seconds.  Hence the subtraction transforms
into N:97 - N:60, yielding 37 s.

1 s earlier, we have 2017-01-01T00:00:35 TAI corresponding to
2016-12-31T23:59:59 UTC.  To compute TAI-UTC we need to subtract
2016-12-31T23:59:59 from 2017-01-01T00:00:35.  These time labels are
clearly in consecutive minutes; the subtraction is of the form (N+1):35
- N:59.  Finding that in the seconds position the subtrahend is larger
than the minuend, we must borrow from the minutes position.  We know
that the minute in question has 61 seconds, so borrowing the one minute
amounts to borrowing 61 seconds.  Hence the subtraction transforms into
N:96 - N:59, yielding 37 s.

35 s earlier than that, we have 2017-01-01T00:00:00 TAI corresponding
to 2016-12-31T23:59:24 UTC.  To compute TAI-UTC we need to subtract
2016-12-31T23:59:24 from 2017-01-01T00:00:00.  These time labels are
clearly in consecutive minutes; the subtraction is of the form (N+1):00
- N:24.  Finding that in the seconds position the subtrahend is larger
than the minuend, we must borrow from the minutes position.  We know
that the minute in question has 61 seconds, so borrowing the one minute
amounts to borrowing 61 seconds.  Hence the subtraction transforms into
N:61 - N:24, yielding 37 s.

1 s earlier than that, we have 2016-12-31T23:59:59 TAI corresponding
to 2016-12-31T23:59:23 UTC.  To compute TAI-UTC we need to subtract
2016-12-31T23:59:23 from 2016-12-31T23:59:59.  These time labels are
clearly in the same minute; the subtraction is of the form N:59 - N:23.
Finding that in the seconds position the minuend is larger than the
subtrahend, we have no need to borrow from the minutes position.
Hence the subtraction in the form N:59 - N:23 directly yields 36 s.

Comparing these, we find that TAI-UTC incremented at 2017-01-01T00:00:00
TAI, 2016-12-31T23:59:24 UTC.  In general this method yields TAI-UTC
changing at 00:00:00 TAI.

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

I'm not assuming that, and would be foolish to assume it since I know it
to be false.  What I *am* doing is incrementing MJD by 1/86400 per second
within each day, as well as by 1 per complete day (midnight to midnight).
This does indeed cause two seconds to map to the same MJD range where
there is a positive leap second.  It also causes some MJD values to
be skipped at a negative leap second.  This is how MJD is meant by the
defining expressions in tai-utc.dat.

I've seen a suggestion that MJD for UTC should instead be computed to
increase by 1/LOD per second within each day, where LOD is the number of
seconds in that UTC day (normally 86400 but sometimes 86401 or 86399).
I haven't seen this in practical use.  It amounts to a type of leap smear,
and has all the advantages and disadvantages of such.  Computing TAI-UTC
on this basis would yield a continuous change over the day of the leap,
rather than a step change.

Where I've wanted a continuous MJD for UTC, I've actually used the MJD
derived from UTC-SLS (a 1000 s smear).

Any kind of MJD for UTC must be used with caution, due to having
discontinuities in either phase or frequency.

-zefram