[threeten-dev] Leap seconds and the Java time-scale

Fri Apr 5 08:43:15 PDT 2013

I've been corresponding with Zefram recently about the API, specifically
around leap seconds and the Java time-scale that we define to avoid
exposing leap seconds. Zerfram knows far more than I do about
UTC/UT1/UT2/.. and the alphabet soup of time-scale acronyms, as has
provided some excellent feedback, which I have permission to publish
excerpts of for transparancy (at the end of this email).

I'm currently proposing this as the new text for the time-scale. Its more
precise than we currently have, yet doesn't change any code or
implementation behaviour, and also allows for future change.

The current text is in the class Javadoc here:
http://hg.openjdk.java.net/threeten/threeten/jdk/file/e184e025210a/src/share/classes/java/time/Instant.java

"
The Java time scale divides each calendar day into exactly 86400
subdivision, known as seconds.  These seconds may differ from the SI
second.  It closely matches the de facto international civil time
scale, the definition of which changes from time to time.

The Java time scale has slightly different definitions for different
segments of the time-line, each based on the consensus international
time scale that is used as the basis for civil time. Whenever the
internationally-agreed time scale is modified or replaced, a new
segment of the Java time scale must be defined for it.  Each segment
must meet these requirements:

 * the Java time scale shall closely match the underlying
international civil time scale;

 * the Java time scale shall exactly match the international civil
time scale at noon each day on the prime meridian (Greenwich);

 * the Java time scale shall have a precisely-defined relationship to
the international civil time scale.

There are currently, as of 2013, two segments in the Java time-scale.

For the segment from 1972-11-03 (UTC) (exact boundary discussed below)
until further notice, the consensus international time scale is UTC
(with leap seconds).  In this period, the Java time scale is identical
to UTC-SLS [hyperlink]. This is identical to UTC on days that do not
have a leap second. On days that do have a leap second, the leap
second is spread equally over the last 1000 seconds of the day,
maintaining the appearance of exactly 86400 seconds per day.

Implementations of the JSR-310 API are not required to provide any
clock that is sub-second accurate, or indeed accurate at all, or that
progresses monotonically or smoothly. Implementations are therefore
not required to actually perform the UTC-SLS slew or to otherwise be
aware of leap seconds. Only implementations that claim sub-second
accuracy are obliged to distinguish between the various flavours of
UT, and how conformant they are with the time-scale.

For the segment prior to 1972-11-03 (UTC), extending back arbitrarily
far, the consensus international time scale is defined to be UT1
extrapolated proleptically. This is equivalent to the (mean) solar
time on the prime meridian (Greenwich). If implementing based on a
specific set of UT1 data, then the exact boundary is where UT1 = UTC,
which may be up to 18 hours later than 1972-11-03T00:00Z (UTC)
depending on the UT1 data.

For the segment prior to 1972-11-03 (UTC), extending back arbitrarily
far, the consensus international time scale is defined to be UT1
extrapolated proleptically. This is equivalent to the (mean) solar
time on the prime meridian (Greenwich). If implementing based on a
specific set of UT1 data, then the exact boundary is where UT1 = UTC,
which may be up to 36 hours earlier or later than 1972-11-03T00:00Z
(UTC) depending on the UT1 data.
"

Feedback welcome.
Stephen

-----------------------------------------------------------------

Forwarded conversation
Subject: Java definitions
------------------------

From: *Stephen Colebourne* <scolebourne at joda.org>
Date: 30 March 2013 00:09
To: Zefram

Hi Zefram,
Good to meet you on Thursday.

I've updated the definition slightly, to require a clear algorithm as
part of the time-scale, and refer to UTC-SLS as the approved
algorithm. This seems to me to be a firmer definition than before,
without totally closing the door to other implementations and changes
(which I need to allow for). In particular, if UTC were to be changed
in 2014 to have an official smoothing algorithm other than UTC-SLS,
then I want some wiggle room to be able to adapt.

 * Given the complexity of accurate timekeeping described above, this
Java API defines
 * its own time-scale with a simplification. The Java time-scale is
defined as follows:
 * <p><ul>
 * <li>midday will always be exactly as defined by the agreed
international civil time</li>
 * <li>other times during the day will be broadly in line with the
agreed international civil time</li>
 * <li>the day will be divided into exactly 86400 subdivisions,
referred to as "seconds"</li>
 * <li>the Java "second" may differ from an SI second</li>
 * <li>a well-defined algorithm must be specified to map each second
in the accurate agreed
 *  international civil time to each "second" in this time-scale</li>
 * </ul><p>
 * Agreed international civil time is the base time-scale agreed by
international convention,
 * which in 2012 is UTC (with leap-seconds).
 * <p>
 * In 2012, the definition of the Java time-scale is the same as UTC
for all days except
 * those where a leap-second occurs. On days where a leap-second does
occur, the time-scale
 * effectively eliminates the leap-second, maintaining the fiction of
86400 seconds in the day.
 * The approved well-defined algorithm to eliminate leap-seconds is
specified as
 * <a href="http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/">UTC-SLS</a>.
 * <p>
 * UTC-SLS is a simple algorithm that smoothes the leap-second over
the last 1000 seconds of
 * the day, making each of the last 1000 seconds 1/1000th longer or
shorter than an SI second.
 * Implementations built on an accurate leap-second aware time source
should use UTC-SLS.
 * Use of a different algorithm risks confusion and misinterpretation
of instants around a
 * leap-second and is discouraged.

On the definition before 1972, I'm reluctant to get too deep into the
definition (especially given that it doesn't really matter to anyone
writing business software today). I'm proposing adding the final ", as
per the principles of UT1". Anything else seems like over-definition,
given that we handle dates back to one billion years BCE where no
standards apply and where the definition "the solar day" seems as good
as it can get.

 * One final problem is the definition of the agreed international
civil time before the
 * introduction of modern UTC in 1972. This includes the Java epoch of
{@code 1970-01-01}.
 * It is intended that instants before 1972 be interpreted based on
the solar day divided
 * into 86400 subdivisions, as per the principles of UT1.

Hope these are better!
thanks
Stephen

----------
From: *Zefram*
Date: 2 April 2013 15:45
To: Stephen Colebourne <scolebourne at joda.org>

Stephen Colebourne wrote:
>I've updated the definition slightly, to require a clear algorithm as
>part of the time-scale, and refer to UTC-SLS as the approved
>algorithm.

The wording now mixes up requirements with definitions.  Most of the
old definition now constitutes requirements, and the change in status
should be reflected in the structure of the text.  It could also do
with clarification about how the precise definition is to be reached,
and some other bits.

>On the definition before 1972, I'm reluctant to get too deep into the
>definition (especially given that it doesn't really matter to anyone
>writing business software today).

It doesn't take very much wording.  It does need to be segregated out
so that it's easy for the majority to ignore.

Here's how I'd write the definition:

    The Java time scale divides each calendar day into exactly 86400
    seconds.  These seconds may differ from the SI second.  It closely
    matches the de facto international standard time scale, the definition
    of which changes from time to time.

    The Java time scale is constructed piecewise from segments each based
    on the consensus international time scale that is used as the basis
    for civil time.  Whenever the internationally-agreed time scale is
    modified or replaced, a new piece of the Java time scale must be
    defined for it.  Each segment must meet these requirements:

    * the Java time scale shall closely match the underlying international
      time scale;

    * the Java time scale shall exactly match the international time
      scale at noon each day;

    * the Java time scale shall have a precisely-defined relationship
      to the international time scale.

    For the period from 1972-10-27 (exact boundary discussed below)
    until further notice, the consensus international time scale is
    UTC (with leap seconds).  In this period, the Java time scale is
    identical to UTC-SLS.  This is identical to UTC on days that do not
    have a leap second.  On days that do have a leap second, the leap
    second is spread over the last 1000 seconds of the day, maintaining
    the appearance of exactly 86400 seconds per day.

    Implementations of the JSR-310 API are not required to provide
    any clock that is sub-second accurate, or indeed accurate at all,
    or that progresses monotonically or smoothly.  Implementations are
    therefore not required to actually perform the UTC-SLS slew or to
    otherwise be aware of leap seconds.  Only implementations that claim
    sub-second accuracy are obliged to distinguish between the various
    flavours of UT.

    For the period prior to 1972-10-27, extending back arbitrarily far,
    the consensus international time scale is an ambiguous selection
    among UT1 and its smoothed variants, and the Java time scale is
    identical to UT2R.  The exact boundary between this segment and the
    UTC-SLS segment is the instant when UT2R = UTC somewhere between
    1972-10-26T12 and 1972-10-28T00.

If the earlier segment should match UT1 instead of UT2R, the boundary
would be when UT1 = UTC around 1972-11-03, specified range 1972-11-03T00
to 1972-11-04T12.  The source I'm using for this computation declares
an uncertainty of 1.9 ms in UT1-UTC, corresponding to uncertainty of
about 14 hours in the time at which the time scales cross.  Annoyingly,
1972 began with UTC already marginally ahead of both UT1 and UT2R,
so there's no crossing of the time scales until after the 1972-06-30 leap.

-zefram

----------
From: *Stephen Colebourne* <scolebourne at joda.org>
Date: 2 April 2013 18:12
To: Zefram

On 2 April 2013 15:45, Zefram <zefram at fysh.org> wrote:
> Here's how I'd write the definition:

I like most of this. My thoughts are interspersed:

>     The Java time scale divides each calendar day into exactly 86400

I think I'd say "86400 subdivisions, referred to as seconds"

>     seconds.  These seconds may differ from the SI second.  It closely
>     matches the de facto international standard time scale, the definition
>     of which changes from time to time.

"de facto international standard time scale" to "de facto
international civil time scale"
I still think that defining either UT1 or UR2R is wrong for the far
past. Looking into their history, neither makes much sense as even the
term UT is quite recent. I've seen other sources that suggest that UT2
isn't much used, at least compared to UT1.

Sticking to something that clearly links to the solar day for the far
past is more in line with actual history, where the sun rules the day.

Perhaps the best option is to use UT1 back to an earlier point in time
(such as the creation of UT1) and then a descriptive "solar day"
before that - ie. adding another segment to the time-scale.

thanks for your thoughts
Stephen

----------
From: *Zefram*
Date: 3 April 2013 08:47
To: Stephen Colebourne <scolebourne at joda.org>

Stephen Colebourne wrote:
>I think I'd say "86400 subdivisions, referred to as seconds"

>"de facto international standard time scale" to "de facto
>international civil time scale"

These are fine.

>I still think that defining either UT1 or UR2R is wrong for the far
>past. Looking into their history, neither makes much sense as even the
>term UT is quite recent.

It doesn't matter when the term was defined.  The time scales are well
defined for any period when the Earth has a solid surface.

>                         I've seen other sources that suggest that UT2
>isn't much used, at least compared to UT1.

These days UT2 is essentially historical, yes.  UT1 is actual Earth
rotation, so we look at that if we're interested in Earth orientation,
and it's what UTC tracks since 1972.  Prior to 1972, UTC tracked UT2.
That usage derives from the pre-atomic practice of synchronising time
signals directly to UT2.  This arose because, in that era, UT2 was the
state of the art in generating a stable time scale.  Note, this is a
logically distinct purpose from tracking Earth orientation.  Nowadays,
the state of the art in generating a stable time scale from Earth rotation
is UT2R.  (The state of the art in generating a stable time scale without
that constraint is TAI, of course.)

>Sticking to something that clearly links to the solar day for the far
>past is more in line with actual history, where the sun rules the day.

Any form of UT does that.  UT1 is by definition the solar day on
the prime meridian, and all the other forms of UT closely track it.
UTC isn't available for the far past, but UT1, and hence UT2R et al, are.

>(such as the creation of UT1)

UT1 wasn't created per se.  The concept of UT1 is applicable
retrospectively.  (Unlike UTC, which can't exist for an era before it
was defined.)

The term "UT1" was devised to specifically refer to the globally-coherent
form of UT, when it became necessary to correct for polar motion.
The term "UT" was devised as an unambiguous and neutral name for what
was already known as "GMT".  There's continuity in the definitions.

-zefram

----------
From: *Stephen Colebourne* <scolebourne at joda.org>
Date: 3 April 2013 14:42
To: Zefram

Is there a good link for UT1 as defined or implied in the far past?
>From what you say, it sounds like it would be acceptable to use, as
"the solar day onthe prime meridian" is exactly what I'm trying to
define.

Can I forward suitable sections of these emails to a public mailing
list for transparancy?

thanks
Stephen

----------
From: *Zefram*
Date: 3 April 2013 15:53
To: Stephen Colebourne <scolebourne at joda.org>

Stephen Colebourne wrote:
>Is there a good link for UT1 as defined or implied in the far past?

The current definition of UT1, which is unfortunately
a bit opaque, comes from the IAU 2000 meeting
<http://syrte.obspm.fr/IAU_resolutions/Resol-UAI.htm>, resolution B1.8.
It defines UT1 as a linear transformation of the Earth Rotation Angle
(ERA), with no mention of range limits.  (In this definition it is
therefore not quite the same thing as solar time on the prime meridian,
as it's affected by irregularities in the Earth's orbit.  But the orbit is
much more stable and more precisely understood than the Earth's rotation,
so this is not a practical issue.  Also liable to be fixed by a later
redefinition.)

The Earth Rotation Angle is defined (by the same resolution) in terms of
the Non-Rotating Origin (NRO) reference frame.  (It turns out that the
Non-Rotating Origin does in fact rotate, very slowly.  This too is likely
to motivate a future redefinition.)  The NRO is defined by a 1978 paper
by Bernard Guinot <http://adsabs.harvard.edu/abs/1979IAUS...82....7G>.
This too makes no mention of range limits.  The applicability of the
definitions to distant historical times is (I reckon) implicit; it's
routine for astronomers to deal with large spans of time.

As the definitions aren't explicit, it's useful to look at actual
astronomical practice.  The relevant application that immediately
comes to mind is the use of ancient historical records of eclipses
to determine the relationship between UT1 and TT (or other similarly
uniform time scale).  (Orbital calculations tell us very precisely when
eclipses occurred in physical time, and a written record saying where
(geographically) an eclipse was observed thus tells us which way the
Earth was oriented at the time.)  Steve Allen makes some mention of
this at <http://www.ucolick.org/~sla/leapsecs/dutc.html>, with a nice
graph at <http://www.ucolick.org/~sla/leapsecs/ancient.pdf>, looking
back to -500 CE.  He refers to a 2001 paper by Morrison & Stephenson
<http://adsabs.harvard.edu/abs/2004JHA....35..327M>, which refers to
TT and UT for dates as far back as -1000 CE without any comment about
the proleptic usage.  (It does comment on the negative year number
convention.)

If you want a stronger answer than this, you'd better ask an astronomer.

>"the solar day onthe prime meridian" is exactly what I'm trying to
>define.

Yes, "UT1" is the standard name for (mean) solar time on the prime
meridian.

>Can I forward suitable sections of these emails to a public mailing
>list for transparancy?

Sure.  Everything I've said here can be made public.

-zefram

----------
From: *Stephen Colebourne* <scolebourne at joda.org>
Date: 4 April 2013 14:34
To: Zefram

On 3 April 2013 15:53, Zefram <zefram at fysh.org> wrote:
>>"the solar day onthe prime meridian" is exactly what I'm trying to
>>define.
>
> Yes, "UT1" is the standard name for (mean) solar time on the prime
> meridian.

OK, that should be OK then. So how about (most your text, but with a
few tweaks):

The Java time scale divides each calendar day into exactly 86400
subdivision, known as seconds.  These seconds may differ from the SI
second.  It closely matches the de facto international civil time
scale, the definition of which changes from time to time.