[LEAPSECS] JD & MJD, UT1 & UTC

[Zefram]

Steve Summit wrote:
>And this is eerily similar to the idea of using a struct
>timespec with a nonnormalized tv_nsec field.

For that matter, tm_sec==60 is the same class of trick too.  We're just
varying at which digit position we stuff in an out-of-radix value.

>        the UTC-aware son-of-time_t representation I've been
>exploring using the pair (days since 1970, seconds within day).)

I've used (days-since-epoch, seconds-since-midnight) representations too.
The (MJDN, MJDF) tuple is precisely equivalent to that, just with the
time-of-day scaled.  (I like to use bignum-ratio representations of MJDF,
rather than floating point, so that it can exactly represent integral
seconds.)  This class of representation is really the most natural way
to approach UTC: its fundamental units are the days and the seconds,
so just counting both of those works nicely.

>Now that's a cute idea.  (But when you say "It's tempting",
>do you really mean "It's tempting, but don't do it"? :-) )

If actually implemented, the extreme rarity of the "A" digit would tend
to make it confusing.  It's much weirder than ":60".  Another thing that
puts me off is that there's no equivalent trick for a timezone-relative
CJD, where the leap second could arise at any minute of the day.
For that matter, it doesn't even translate nicely to JD, where one
could introduce an extra digit, but it would be duplicating the "5"
digit rather than having a novel value.  So although the trick works
for the specific case of MJD, it gets no support from its conceptual
context, and I'm dubious about the value of a mechanism so exceptional.
That's the cause of a lot of the trouble we have with leap seconds.
The (MJDN, MJDF) tuple and equivalents, by contrast, make the leap second
look a lot less exceptional.

-zefram