[threeten-dev] [threeten-develop] Leap seconds and the Java time-scale
Douglas Surber
douglas.surber at oracle.com
Fri Apr 5 12:59:48 PDT 2013
Given the lack of requirements for a clock it would be useful to add
some methods that characterize the clock.
Example:
public enum Monotonicity { UNKNOWN; NONMONOTONIC;
MONOTONIC_DEPENDENT; MONOTONIC_INDEPENDENT; }
public Monotonicity getMonotonicity();
public Duration getPrecision();
MONOTONIC_DEPENDENT means the clock is monotonic so long as some
other time source external to the JVM (the OS) is monotonic. If the
sysadmin changes the system clock, time may go backwards.
MONOTONIC_INDEPENDENT means the clock is monotonic regardless of any
other time source.
getPrecision returns the least Duration such that the passage of that
amount of physical time will guarantee that now() returns a different
value. The returned value is the ideal assuming
MONOTONIC_INDEPENDENT. If getMonoticity returns some other value then
the returned precision will be incorrect when the clock is not
behaving MONOTONIC_INDEPENDENT, such as when the sysadmin is changing
the system clock.
Just thinking out loud.
Douglas
At 11:20 AM 4/5/2013, roger riggs wrote:
>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