[LEAPSECS] alternative to smearing

[Zefram]

Preben Norager wrote:
>We now know that the julian period is not all of history,

Newcomb didn't claim that it is.  It is actually the case that the Julian
Period covers all of *recorded* history (i.e., history that was written
down at the time), and there is some small convenience in that fact.
But in your quotation Newcomb describes JDs as "the number of days
... *before or* after this epoch" (my emphasis).  He envisions negative
JDs, and we have no difficulty extending numbers in that direction as
far as we care to go.  The JD system thus does cover all of history.
For that matter, the Julian Period will end in another 1250 years or so,
but JDs extend forward past that point too.

His main claim there is that the system is "continuous through all
history".  Continuity is a noted feature of the real numbers.

>                                                          and we also know
>that the mean solar day is not an expression of the greatest precision.

True.  In that role, mean solar time (Universal Time, UT) has been
supplanted by Terrestrial Time (TT), Barycentric Coordinate Time (TCB),
and other modern time scales.

>I don't understand why science and astronomy still uses JD and MJD.

The original reasons for using them still hold.  Times on the newer
time scales have always been expressed in terms of JD/MJD, by virtue
of the transferance from UT to Ephemeris Time (ET), and thence to its
relativistically-sound successors TT et al.  On any of these time scales,
the continuity, uniformity, and simplicity of a real-number linear count
remain compelling features.  Hypothetically, if the historical transfer
of JD usage had not occurred, then practicality would require that we
invent some equivalent linear count for the newer time scales.

If there is any time scale that is an exception to the utility of JD,
then it is UTC, by virture of its leaps.  (Either the present leap seconds
or the pre-1972 smaller leaps.)  As discussed a few days ago on another
thread, the irregularly non-uniform lengths of UTC days, as judged by UTC
itself, causes some difficulty in reducing a UTC time to a scalar count.
The resulting count is not continuous.  The discontinuous count is in
fact used for some purposes anyway.  But the demands of practicality
that lead one to use JD for UT1 instead push one towards an integer+real
two-part count, such as (MJDN, seconds-since-midnight), for UTC.

>                                         I don't understand why science and
>astronomy still uses julian calendar days, and not days of the proleptic
>gregorian calendar.

It depends on what one wants to concentrate upon.  The Gregorian
calendar is convenient in placing dates relative to the cycle of seasons.
(It's not very precise in doing so; we can specify solar longitude if
we're really interested in that.)  Often the seasons would just be a
distraction, so one would prefer to avoid specifying that.  If there's
no strong desire either way on that issue, then the simplicity and
uniformity of JD are attractive features.

By the way, there's a problem with your phrasing here around "Julian
calendar days".  You're referring to the linear day count systems such
as Julian Date, but that phrase makes it look as though you're referring
to the Julian calendar.  That's a very different beast, the immediate
predecessor of the Gregorian calendar, and bearing a strong resemblance
to it.

>                    With a simple computer program it is easy to compute
>the exact fraction of days between two times in the proleptic gregorian
>calendar,

Requiring dates to be put through a computer program in order to properly
understand them is still detrimental to comprehension.  It will remain
so as long as the computer program is not neurologically embedded.
This works both ways, of course: JD is a poor way to describe historical
events to the general public, just as the Gregorian calendar is a poor
way to describe orbital events in a technical context.  One must have
due regard to the intended audience.

But no matter how readily available a compuation is, the JD concept
remains essential.  Those calendar computation programs generally work
by converting to JD or something equivalent underneath.  Any computation
of things happening over time is likely to want to describe time in a
linear manner, at least as an internal variable.  Anyone working closely
with this kind of algorithm needs to work in a linear time variable.
Astronomers do this sort of thing quite a lot.

>                                     and for the outreach to the general
>public, I think it would be good for science and astronomy, to use the
>gregorian calendar which the general public understands.

In outreach contexts, sure, there's good reason to use the calendar that
the target audience is already familiar with.  But that's not a reason
to compromise the precision or comprehensibility of communications from
astronomer to astronomer.

>I think my argument here for the civil and scientific use of the Gregorian
>calendar does have something to do with the choice of underlying time
>scale. The general public will never understand leap seconds, and I think
>the general public shall have a time and a calendar they understand.

You're making two parallel arguments here: for the use of the Gregorian
calendar, and for the use of TAI-like days.  The two do not support
each other.  The argument for the use of the Gregorian calendar is
totally independent of the choice of time scale.

The argument that you make for the use of TAI-like days is considerably
weaker than the argument relating to the calendar.  The general public
has limited understanding of leap seconds, true, but it also has limited
understanding of `days' that don't correspond to the motion of the sun
in the sky.  There's no corresponding problem for the argument about
the calendar.

You're welcome to develop both of these public-understanding arguments,
but you'll do better treating them separately.  The details of the two
arguments are quite different.  Each of them is only weakened by tying
it to an essentially unrelated matter.  Only the time scale issue is
relevant to this mailing list; please take the calendar issue elsewhere.

-zefram