[LEAPSECS] JD & MJD, UT1 & UTC

[Zefram]

Tom Van Baak wrote:
>But since some of you are real picky about formal definitions,
>my question is what to do about MJD -- is it UT1-based or it is
>UTC-based?

Both.  Also TAI, TT, TCG, and TCB.  And UT0, UT2, UT1R, UT2R, UTC-SLS, and
other flavours of UT.  The use of JD or MJD doesn't imply which time scale
is being used; rather, it is a way of specifying a date and time-of-day
that can be applied to any of these time scales.  A JD value has nearly
the same status here as a date specified in the Gregorian calendar: such
calendar dates are also used with all of these time scales.  The only
real difference in status is that the Gregorian calendar and sexegesimal
time-of-day also get applied to timezone-relative timing, whereas JD and
MJD preclude the use of timezones.  We have the Chronological Julian Date
(CJD) for timezones.

>And if UTC-based, what's the right thing to do when the day has a +/-
>leap second?

Mostly the right thing is to avoid using JD/MJD, because it gets
confusing.  The expressions that do use JD/MJD with UTC, such as the
defining expressions for rubber UTC in tai-utc.dat, work on the basis that
MJD is always the expected integer (and JD the expected half-integer)
at 00:00:00 UTC, and that within a UTC day JD/MJD increases by 1/86400
per UTC second.  This means there's a discontinuity in JD/MJD at the end
of a positive leap, with JD/MJD values during the leap being ambiguous
with the first second of the following day.  One must understand from
context which second one is dealing with.

It is sometimes useful to split an MJD value into integral and fractional
parts.  The integral part is the Modified Julian Day Number (MJDN),
and I call the fractional part the Modified Julian Day Fraction (MJDF).
By definition, MJD = MJDN + MJDF.  When applied to a leapless time scale,
MJDN = floor(MJD), and MJDF is always in the range [0, 1).  But when
applied to UTC, MJDN is best taken to be the number corresponding to
the UTC day (even if it started more than 86400 seconds ago), and MJDF
gives the time within that day (even if that's more than 86400 seconds).
The (MJDN, MJDF) tuple is unambiguous: during a leap second MJDF >= 1.
Even if one doesn't actually need the unambiguous decoding, explicitly
separating these two quantities can make expressions using MJD with
UTC clearer.

If one wants to display a UTC-based MJD value, it's tempting to adopt
a digit with value ten, and use that in the first fractional place to
distinguish a leap second from the following second.  For example, MJD
57753.99999 came during the second preceding the recent leap second,
MJD 57753.A0001 came during the leap second, and MJD 57754.00001 came
during the following second.  I've never implemented this, but I find
it a useful way to think.

-zefram