Julian day numbers and leap seconds

When astronomers count Julian day numbers (time 0 = noon, January 1,
-4712), are the leap seconds included (causing leap second days lengths to
differ), or is each Julian day equally long in atom time? (In case there
is an interest in POSIX/UNIX standardization, I want to get it right. :-))

Hans Aberg

On May 7, 2:07 am, (Hans Aberg) wrote:
When astronomers count Julian day numbers (time 0 = noon, January 1,
-4712), are theleap secondsincluded (causing leap second days lengths to
differ), or is each Julian day equally long in atom time? (In case there
is an interest in POSIX/UNIX standardization, I want to get it right. :-))

POSIX is self-inconsistent in the presence of leap seconds, so I would
assert that there is no way to be sure that you've got it right. See
http://www.ucolick.org/~sla/leapsecs/timescales.html

In article ,
wrote:

When astronomers count Julian day numbers (time 0 = noon, January 1,
-4712), are the leap seconds included (causing leap second days lengths to
differ), or is each Julian day equally long in atom time? (In case there
is an interest in POSIX/UNIX standardization, I want to get it right. :-))

POSIX is self-inconsistent in the presence of leap seconds, so I would
assert that there is no way to be sure that you've got it right.*

This is why I am asking: in order to be able to give a suggestion on the
POSIX/UNIX*standardization mailing list! That is, the method to get it
right, is to change the standard. :-)

See
http://www.ucolick.org/~sla/leapsecs/timescales.html

This seems what I am asking for:

* It should also be noted that the use of JD or MJD for the UTC time scale is
* problematic and ambiguous at the precision of one second. JD and MJD express
* the elapsed count of some form of ``day'' as real numbers along a presumably
* unsegmented, continuous number line. The UTC time scale (and, historically,
* GMT as used in practical situations before the advent of UTC) contains changes
* in rate and discontinuities. In particular, there is no obvious way to
* represent a leap second of UTC (or the smaller leaps present in the available
* forms of GMT and UTC before 1972) using JD or MJD notation.

So it seems that JD and MJD do not count leap seconds. For astronomical
and*calendar synchronization purposes, I believe this is right, as
the*arithmetic*of time calculations becomes easy.

Hans Aberg

In article ,
wrote:

On May 7, 2:07 am, (Hans Aberg) wrote:
When astronomers count Julian day numbers (time 0 = noon, January 1,
-4712), are theleap secondsincluded (causing leap second days lengths to
differ), or is each Julian day equally long in atom time? (In case there
is an interest in POSIX/UNIX standardization, I want to get it right. :-))

POSIX is self-inconsistent in the presence of leap seconds, so I would
assert that there is no way to be sure that you've got it right. See
http://www.ucolick.org/~sla/leapsecs/timescales.html

First, the Julian Day Number is an astronomical time scale, not an
atomic time scale.

The Julian Day Number (JD) is simply a count of days since the
beginning epoch of 1 Jan 4713 BC, 12h UT. Hours, minutes and seconds
are represented as a fraction of the day. If you want to add a leap
second, you can always add a 61th second to some minute. But there's
no way you could nicely fit that within the JD day numbering scheme -
that would require the fractional part of the JD to sometimes become
slightly larger than 1.0 !!! How would you accomplish that?

As used in astronomy, there are two different kinds of JD - neither of
them has any leap seconds:

JD - based on the slightly irregular UT time scale.

JED - based on the uniform ET/TDT/TT time scale, where TT always runs
32.184 seconds ahead of TAI.

http://stjarnhimlen.se/comp/time.html

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

In article ,
(Paul Schlyter) wrote:

First, the Julian Day Number is an astronomical time scale, not an
atomic time scale.

The Julian Day Number (JD) is simply a count of days since the
beginning epoch of 1 Jan 4713 BC, 12h UT.

There are in fact two different types of time scales or calendars:
counting days and measuring absolute time (i.e., from an epoch, time = 0),
though this is not absolutely possible, in view of GR constraints. Both
should be supplied by a computer, but her I am mainly interested in the
latter (see below).

Hours, minutes and seconds
are represented as a fraction of the day.* If you want to add a leap
second, you can always add a 61th second to some minute.* But there's
no way you could nicely fit that within the JD day numbering scheme -
that would require the fractional part of the JD to sometimes become
slightly larger than 1.0 !!!* How would you accomplish that?

I should explain the situation: On the POSIX/UNIX standardization lists,
one is now discussing time stamps, going*down to a small*fraction of a
second, perhaps even down to a nano-second. And one would like to get
these time stamps to work in a*distributed setting, i.e., when
different*computers do these time stamps.
And another requirement is that one should be able to coordinate it to
legal time, that is, what is commonly used by humans.

As used in astronomy, there are two different kinds of JD - neither of
them has any leap seconds:

JD* - based on the slightly irregular UT time scale.

JED - based on the uniform ET/TDT/TT time scale, where TT always runs
* * ** 32.184 seconds ahead of TAI.

http://stjarnhimlen.se/comp/time.html

So taking these requirements together, it seems me best that one would use
some kind of atomic time, but which is well coordinated to the JD system.
The UTC leap seconds could be easily viewed as a*calendar feature. One
could then, ideally sync to get a*combined*computer, atomic
and*astronomical time scale.

So it seems that one should use something like the JED you mention, or
something else related to TAI. But your URL does not define JED.

Paul Schlyter,* Grev Turegatan 40,* SE-114 38 Stockholm,* SWEDEN

It is a small world: I am at Kungsholmstorg, just about a 25 minute walk
from you. :-)

Hans Aberg

On May 8, 2:09 am, (Paul Schlyter) wrote:
First, the Julian Day Number is an astronomical time scale, not an
atomic time scale.

That does not stop geophysicists and atomic clock keepers from using
MJD.
See BIPM's Circular T at ftp://ftp2.bipm.fr/pub/tai/publication

As used in astronomy, there are two different kinds of JD - neither of
them has any leap seconds:

JD - based on the slightly irregular UT time scale.

JED - based on the uniform ET/TDT/TT time scale, where TT always runs
32.184 seconds ahead of TAI.

The universe of JD and MJD usage is bigger than this.
See the Astronomical Almanac and find "Greenwich Sidereal
Date" (GSD). That's a count of sidereal days since the Julian epoch.

Most solar system ephemerides programs employ JD using the TDB
timescale.

Yes, UT is irregular, but so is every time scale as viewed by anyone
in a different reference frame because everything is relative and the
conversions are full 4-dimensional transformations which are non-
linear and depending on time, place, and motion.

TAI is not regular, see TT(BIPM06) at ftp://ftp2.bipm.fr/pub/tai/scale/ttbipm.06
and for that reason 32.184 is not a fixed constant, it is a quantity
to be estimated.

The definitions for TCB and TCG are commonly expressed using JD, see,
e.g.,
http://adsabs.harvard.edu/cgi-bin/np...6A...348..642I
http://www.iers.org/MainDisp.csl?pid=46-25776

It helps if you think of Julian Date as a calendar, not a time-scale.
It is just a counting system. Time scales are things like TAI, TT, TDB
etc.

(It also helps if you think of UT1 as a measure of Earth rotation, not a
time-scale.)

UTC is only defined in a mixed-radix sense, namely as y/m/d/h/m/s,
necessary because during a leap second the seconds counts 58, 59, 60,
00 instead of the usual 58, 59, 00. It is improper (though not
uncommon) to express UTC as a JD.

POSIX should in my opinion support TAI as its fundamental time-scale.
TAI is continuous and measured in SI seconds (on the geoid). A JD in
TAI is perfectly legitimate. POSIX should also support the current and
next TAI-UTC and the TAI at which the new TAI-UTC value will become
true, announced about 6 months ahead. Then all processors can
implement the leap second correctly, without being on a network at the
time and without doing anything at all iffy in a real-time sense. UTC
should be used for all user-interface purposes, so that TAI is hidden.

Patrick Wallace
STFC/RAL Space
__________________________________________________ _____________

In sci.astro.research message
k, Tue, 8 May 2007 09:07:20, Hans Aberg posted:

So it seems that JD and MJD do not count leap seconds. For astronomical
and*calendar synchronization purposes, I believe this is right, as
the*arithmetic*of time calculations becomes easy.


JD and MJD are counts of mean solar days at Greenwich. CJD and CMJD are
counts of mean solar days at the current location. None of them are
really measurements of time; in fact, on a Concorde heading from Europe
to the USA, CJD and CMJD ran backwards; when one is crossing the Date
Line, they jump by a day. They are appropriately used in History and
Civil Administration.

The SI second is a measure of time; it is appropriate for use in the
physical sciences, including almost all of Astronomy.

There should be no problem when each is used in its appropriate field.

Sometimes it is more convenient to use the "wrong" system; that does not
matter for work of less accuracy than (currently) about 1 in 10^8. When
it does matter, one must correct observations into the right system.

The world really needs two types of time signal; one for Date (each
divided into 86400 seconds) and one for Time (giving just SI seconds);
ISTM that we should now be able to afford to distribute the two quite
independently. There would then be no call for Leap Seconds.

Since almost all computing uses Date, all NTP services should be
replaced by NDP services (doing, at least short-term, exactly the same);
and there should in principle be, for those who want it, NSP to
distribute counted SI seconds (broadcast & gps will give more accuracy).

The problem is caused by Astronomers, who need SI time for dynamics but
need subdivided Date for pointing telescopes. Actually sidereal date,
so that's another service to distribute.

There are two (at least) temptations for Astronomers to avoid :
* trying to make a compromise system serve astronomical purposes for
which multiple distinct systems are appropriate.
* trying to force, on non-Astronomers, systems designed solely for the
benefit of Astronomers.


The long-term solution must be for IERS to implement an extended remit :
instead of just watching the Earth go round, they should ensure that it
rotates exactly 360/86400 degrees (with respect to the Mean Sun) in
every SI second. That's 15 arcsecs per SI second - evidently, the
Babylonians should have divided the circle into only 24 Degrees, or had
360 hours per day, or chosen a happy mean.

--
(c) John Stockton, Surrey, UK. Turnpike v6.05 IE 6.
Web URL:http://www.merlyn.demon.co.uk/ - w. FAQish topics, links, acronyms
PAS EXE etc : URL:http://www.merlyn.demon.co.uk/programs/ - see 00index.htm
Dates - miscdate.htm moredate.htm js-dates.htm pas-time.htm critdate.htm etc.

In article ,
Hans Aberg wrote:

In article ,
wrote:

When astronomers count Julian day numbers (time 0 = noon, January 1,
-4712), are the leap seconds included (causing leap second days lengths to
differ), or is each Julian day equally long in atom time? (In case there
is an interest in POSIX/UNIX standardization, I want to get it right. :-))

POSIX is self-inconsistent in the presence of leap seconds, so I would
assert that there is no way to be sure that you've got it right.

This is why I am asking: in order to be able to give a suggestion on the
POSIX/UNIX standardization mailing list! That is, the method to get it
right, is to change the standard. :-)

See
http://www.ucolick.org/~sla/leapsecs/timescales.html

This seems what I am asking for:

It should also be noted that the use of JD or MJD for the UTC time scale is
problematic and ambiguous at the precision of one second. JD and MJD express
the elapsed count of some form of ``day'' as real numbers along a presumably
unsegmented, continuous number line. The UTC time scale (and, historically,
GMT as used in practical situations before the advent of UTC) contains changes
in rate and discontinuities.

GMT didn't have these changes. Prior to 1972, there was an experimental
version of UTC where discontinuities were applied frequently and in steps
of fraction of a second, in order to try to keep UTC within some 0.1 seconds
of UT1. In 1972 this approach was abandoned, leap seconds were applied one
full second at a time, and less frequently (at most 4 times per year, in
practice never more than 2 times per year).

In particular, there is no obvious way to
represent a leap second of UTC (or the smaller leaps present in the available
forms of GMT and UTC before 1972) using JD or MJD notation.

So it seems that JD and MJD do not count leap seconds. For astronomical
and calendar synchronization purposes, I believe this is right, as
the arithmetic of time calculations becomes easy.

Hans Aberg
--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/

In article ,
Hans Aberg wrote:

In article ,
(Paul Schlyter) wrote:

First, the Julian Day Number is an astronomical time scale, not an
atomic time scale.

The Julian Day Number (JD) is simply a count of days since the
beginning epoch of 1 Jan 4713 BC, 12h UT.

There are in fact two different types of time scales or calendars:
counting days and measuring absolute time (i.e., from an epoch, time = 0),
though this is not absolutely possible, in view of GR constraints. Both
should be supplied by a computer, but here I am mainly interested in the
latter (see below).

Hours, minutes and seconds
are represented as a fraction of the day. If you want to add a leap
second, you can always add a 61th second to some minute. But there's
no way you could nicely fit that within the JD day numbering scheme -
that would require the fractional part of the JD to sometimes become
slightly larger than 1.0 !!! How would you accomplish that?

I should explain the situation: On the POSIX/UNIX standardization lists,
one is now discussing time stamps, going down to a small fraction of a
second, perhaps even down to a nano-second. And one would like to get
these time stamps to work in a distributed setting, i.e., when
different computers do these time stamps.
And another requirement is that one should be able to coordinate it to
legal time, that is, what is commonly used by humans.

The standard UNIX timestamp counts seconds since 1 Jan 1970 00:00:00,
I believe in the PST time zone (UT-8h), and leap seconds are ignored.
This means that the UNIX timestamp isn't an accurate indicator of the
actual time difference between two such time stamps, if there has
been one or more leap seconds in between.

Basically, there are two choices:

1. Let the time stamp represent a uniform time scale, such as TAI, or
GPS time, or any other time with a constant offset from TAI. This
makes it easy to compute the actual time difference between two time
stamps: a simple subtraction will accomplish that. But if you want to
convert the time stamp to civil time, leap seconds must be accounted
for. Past leap seconds can be stored in a table, but future leap
seconds cannot be predicted - they are announced a few months in
advanced. I.e. there must be some means to add future leap seconds
to the leap second table, when these are announced.

2. Let the time stamp represent civil time, i.e. UTC. No conversion
need to be performed to get civil time. But if you need an accurate
measure of the time difference between two time stamps, leap seconds
must be accounted for. And again, future leap seconds cannot be
predicted.

Neither alternative is ideal - they both shade the disadvantage of the
unpredictability of future leap seconds. However, in the future a
third alternative may be available:

3. Stop introducing leap seconds, and keep UTC at its current offset
from TAI. Let UTC slowly drift away from UT1, and when the difference
starts to approach one hour after a number of centuries, introduce a
leap hour instead:

http://iraf.noao.edu/~seaman/leap/
http://iraf.noao.edu/~seaman/leap/GPS-Nov99_Innov.pdf
http://www.ucolick.org/~sla/leapsecs/

That leap hour can be announced several decades in advanced, giving
computer people plenty of time to adjust their systems accordingly.
If this proposal is accepted, the latest leap second will also be
the last leap second.


In general, computer buffs are in favor if this proposal, while
astronomers tend to dislike it.


As used in astronomy, there are two different kinds of JD - neither of
them has any leap seconds:

JD - based on the slightly irregular UT time scale.

JED - based on the uniform ET/TDT/TT time scale, where TT always runs
32.184 seconds ahead of TAI.

http://stjarnhimlen.se/comp/time.html

So taking these requirements together, it seems me best that one would use
some kind of atomic time, but which is well coordinated to the JD system.
The UTC leap seconds could be easily viewed as a calendar feature. One
could then, ideally sync to get a combined computer, atomic
and astronomical time scale.

So it seems that one should use something like the JED you mention, or
something else related to TAI. But your URL does not define JED.

Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN

It is a small world: I am at Kungsholmstorg, just about a 25 minute walk
from you. :-)

Hans Aberg

Indeed! :-)

--
----------------------------------------------------------------
Paul Schlyter, Grev Turegatan 40, SE-114 38 Stockholm, SWEDEN
e-mail: pausch at stockholm dot bostream dot se
WWW: http://stjarnhimlen.se/