[threeten-dev] [threeten-develop] Leap seconds and the Java time-scale
roger riggs
roger.riggs at oracle.com
Fri Apr 5 11:20:45 PDT 2013
Hi Stephen,
It seems like a reasonable description.
The lack of requirements for to be a clock (monotonic, accurate, etc),
may put off some application developers. Where will they go for assurances
that make their applications run reliably.
The last two paragraphs seems to be duplicated except for the difference
between 18 and 36 hours.
Roger
On 4/5/2013 11:43 AM, Stephen Colebourne wrote:
> 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
> <mailto: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/
> <http://www.cl.cam.ac.uk/%7Emgk25/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
> <mailto: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
> <mailto:scolebourne at joda.org>>
> Date: 2 April 2013 18:12
> To: Zefram
>
> On 2 April 2013 15:45, Zefram <zefram at fysh.org
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <http://www.ucolick.org/%7Esla/leapsecs/dutc.html>>, with a nice
> graph at <http://www.ucolick.org/~sla/leapsecs/ancient.pdf
> <http://www.ucolick.org/%7Esla/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
> <mailto:scolebourne at joda.org>>
> Date: 4 April 2013 14:34
> To: Zefram
>
> On 3 April 2013 15:53, Zefram <zefram at fysh.org
> <mailto: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.
>
> 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.
>
> thanks
> Stephen
>
>
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
>
>
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop
More information about the threeten-dev
mailing list