threeten-develop Mailing List for threeten (Page 3)
Status: Alpha
Brought to you by:
scolebourne
You can subscribe to this list here.
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2011 |
Jan
(15) |
Feb
|
Mar
(22) |
Apr
(4) |
May
(2) |
Jun
(6) |
Jul
(14) |
Aug
|
Sep
(18) |
Oct
(64) |
Nov
(10) |
Dec
(22) |
2012 |
Jan
(18) |
Feb
(43) |
Mar
(43) |
Apr
(38) |
May
(98) |
Jun
(71) |
Jul
(47) |
Aug
(33) |
Sep
(45) |
Oct
(77) |
Nov
(32) |
Dec
(251) |
2013 |
Jan
(112) |
Feb
(76) |
Mar
(41) |
Apr
(18) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(7) |
2014 |
Jan
(15) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(8) |
Nov
(5) |
Dec
|
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: roger r. <rog...@or...> - 2013-04-08 19:05:44
|
Hi, Practically, I think the default is that Java time uses by the system clock and does not modify its time keeping behavior. The Java APIs are unaware of and do not try to compensate for or correct to improve the accuracy, monotonicity or other aspects of the system clock. It might also be constructive to say that the default Clock uses or stays in sync with System.currentTimeMillis. Following the last leap year incident and NNTP glitches I think we concluded that drift between java.time and System.currentTimeMillis or the system clock would be counter productive in general and cause more problems that it solves. Roger On 4/8/2013 11:57 AM, roger riggs wrote: > Hi, > > I expect most developers to make optimistic assumptions and ignore the > odd cases. > > For those that care, they can implement Clocks that behave to meet the > more detailed requirements. > > I would suggest allowing the Clock to throw an exception in the case > where it is > not monotonic; that's the most likely application assumption that is > likely to > cause bugs. Either the application can handle it or at least not > proceed. > > Roger > > On 4/8/2013 11:22 AM, Douglas Surber wrote: >> At 03:25 AM 4/7/2013, Stephen Colebourne wrote: >>> On 5 April 2013 20:59, Douglas Surber <dou...@or...> >>> wrote: >>>> Given the lack of requirements for a clock it would be useful to >>> add >>>> some methods that characterize the clock. >>> I guess that the API you suggest is feasible, but I'm not sure when >>> users would use it. My feeling is that users won't be iterating >>> around >>> a list of clocks to find one with particular characteristics, >>> instead >>> there wil simply be a decision during coding time to chose one. >> Agreed but they might code differently depending on the properties of >> the clock. For example, it may be possible to use a quick simple >> algorithm with a monotonic, high precision clock but necessary to use >> a more complicated, slower algorithm with a possibly non-monotonic or >> low precision clock. >> >> At some level an implementation must specify these properties of each >> Clock. They can be human readable via JavaDoc or machine readable. >> Making them machine readable will insure that every implementation >> specifies them in a well defined way. It incidentally makes the >> information available to code. >> >> This is not a high priority item, but I think it is at least worth >> considering. >> >> Douglas >> > |
From: roger r. <rog...@or...> - 2013-04-08 15:57:52
|
Hi, I expect most developers to make optimistic assumptions and ignore the odd cases. For those that care, they can implement Clocks that behave to meet the more detailed requirements. I would suggest allowing the Clock to throw an exception in the case where it is not monotonic; that's the most likely application assumption that is likely to cause bugs. Either the application can handle it or at least not proceed. Roger On 4/8/2013 11:22 AM, Douglas Surber wrote: > At 03:25 AM 4/7/2013, Stephen Colebourne wrote: >> On 5 April 2013 20:59, Douglas Surber <dou...@or...> >> wrote: >>> Given the lack of requirements for a clock it would be useful to >> add >>> some methods that characterize the clock. >> I guess that the API you suggest is feasible, but I'm not sure when >> users would use it. My feeling is that users won't be iterating >> around >> a list of clocks to find one with particular characteristics, >> instead >> there wil simply be a decision during coding time to chose one. > Agreed but they might code differently depending on the properties of > the clock. For example, it may be possible to use a quick simple > algorithm with a monotonic, high precision clock but necessary to use > a more complicated, slower algorithm with a possibly non-monotonic or > low precision clock. > > At some level an implementation must specify these properties of each > Clock. They can be human readable via JavaDoc or machine readable. > Making them machine readable will insure that every implementation > specifies them in a well defined way. It incidentally makes the > information available to code. > > This is not a high priority item, but I think it is at least worth > considering. > > Douglas > |
From: Douglas S. <dou...@or...> - 2013-04-08 15:22:41
|
At 03:25 AM 4/7/2013, Stephen Colebourne wrote: >On 5 April 2013 20:59, Douglas Surber <dou...@or...> >wrote: > > Given the lack of requirements for a clock it would be useful to > add > > some methods that characterize the clock. > >I guess that the API you suggest is feasible, but I'm not sure when >users would use it. My feeling is that users won't be iterating >around >a list of clocks to find one with particular characteristics, >instead >there wil simply be a decision during coding time to chose one. Agreed but they might code differently depending on the properties of the clock. For example, it may be possible to use a quick simple algorithm with a monotonic, high precision clock but necessary to use a more complicated, slower algorithm with a possibly non-monotonic or low precision clock. At some level an implementation must specify these properties of each Clock. They can be human readable via JavaDoc or machine readable. Making them machine readable will insure that every implementation specifies them in a well defined way. It incidentally makes the information available to code. This is not a high priority item, but I think it is at least worth considering. Douglas >Stephen > > > > > > 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 > >------------------------------------------------------------------------------ >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 >thr...@li... >https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2013-04-07 10:25:54
|
On 5 April 2013 20:59, Douglas Surber <dou...@or...> wrote: > Given the lack of requirements for a clock it would be useful to add > some methods that characterize the clock. I guess that the API you suggest is feasible, but I'm not sure when users would use it. My feeling is that users won't be iterating around a list of clocks to find one with particular characteristics, instead there wil simply be a decision during coding time to chose one. Stephen > > 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 |
From: Stephen C. <sco...@jo...> - 2013-04-07 10:21:50
|
On 5 April 2013 19:20, roger riggs <rog...@or...> wrote: > 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 accuracy of the clock is something for the implementation to describe. For OpenJDK it should @implNote on the Clock class. Stephen |
From: Douglas S. <dou...@or...> - 2013-04-05 20:00:07
|
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* <sco...@jo... >><mailto:sco...@jo...>> >>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 <sco...@jo... >><mailto:sco...@jo...>> >> >> >>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* <sco...@jo... >><mailto:sco...@jo...>> >>Date: 2 April 2013 18:12 >>To: Zefram >> >>On 2 April 2013 15:45, Zefram <ze...@fy... >><mailto:ze...@fy...>> 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 <sco...@jo... >><mailto:sco...@jo...>> >> >>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* <sco...@jo... >><mailto:sco...@jo...>> >>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 <sco...@jo... >><mailto:sco...@jo...>> >> >> >>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* <sco...@jo... >><mailto:sco...@jo...>> >>Date: 4 April 2013 14:34 >>To: Zefram >> >>On 3 April 2013 15:53, Zefram <ze...@fy... >><mailto:ze...@fy...>> 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 >>thr...@li... >>https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: roger r. <rog...@or...> - 2013-04-05 18:21:05
|
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* <sco...@jo... > <mailto:sco...@jo...>> > 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 <sco...@jo... > <mailto:sco...@jo...>> > > > 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* <sco...@jo... > <mailto:sco...@jo...>> > Date: 2 April 2013 18:12 > To: Zefram > > On 2 April 2013 15:45, Zefram <ze...@fy... > <mailto:ze...@fy...>> 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 <sco...@jo... > <mailto:sco...@jo...>> > > 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* <sco...@jo... > <mailto:sco...@jo...>> > 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 <sco...@jo... > <mailto:sco...@jo...>> > > > 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* <sco...@jo... > <mailto:sco...@jo...>> > Date: 4 April 2013 14:34 > To: Zefram > > On 3 April 2013 15:53, Zefram <ze...@fy... > <mailto:ze...@fy...>> 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 > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2013-04-05 15:43:45
|
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* <sco...@jo...> 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 <sco...@jo...> 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* <sco...@jo...> Date: 2 April 2013 18:12 To: Zefram On 2 April 2013 15:45, Zefram <ze...@fy...> 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 <sco...@jo...> 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* <sco...@jo...> 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 <sco...@jo...> 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* <sco...@jo...> Date: 4 April 2013 14:34 To: Zefram On 3 April 2013 15:53, Zefram <ze...@fy...> 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 |
From: Stephen C. <sco...@jo...> - 2013-03-29 12:53:15
|
DateTimeFormatterBuilder - the comment lines beneath the map of fields (line 1662) should be updated to say what Y does "310 - w, W and Y are localized forms matching LDML" DateTimeFormatterBuilder - The comments are wrong for u, y and Y for 4 letters, as the code uses EXCEEDS_PAD, not NORMAL shoud be "yyyy 4 appendValue(ChronoField.YEAR_OF_ERA, 4, 19, SignStyle.EXCEEDS_PAD);" DateTimeFormatterBuilder - The toString() in the printer-parser now has the same text for e and c. I didn't have a problem with the old style, although the new style is probably clearer. TCKWeekFields, line 492 has incorrect indentation These are all minor things, so I'm happy for direct push without further review if you want. thanks Stephen On 28 March 2013 19:49, roger riggs <rog...@or...> wrote: > Please review updates to DateTimeFormatter* to implement > CLDR behavior for pattern letters 'Y' and 'w'. > > Hooked the WeekFields for WeekBasedYear to the corresponding pattern > letters. > Added tests, updated the javadoc/spec. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ > > Thanks, Roger > > > > > ------------------------------------------------------------------------------ > Own the Future-Intel(R) Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. Compete > for recognition, cash, and the chance to get your game on Steam. > $5K grand prize plus 10 genre and skill prizes. Submit your demo > by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2 > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: roger r. <rog...@or...> - 2013-03-28 19:50:03
|
Please review updates to DateTimeFormatter* to implement CLDR behavior for pattern letters 'Y' and 'w'. Hooked the WeekFields for WeekBasedYear to the corresponding pattern letters. Added tests, updated the javadoc/spec. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ Thanks, Roger |
From: Stephen C. <sco...@jo...> - 2013-03-26 17:42:07
|
Line 120 has bad Javadoc formating. Otherwise looks good to push Stephen On 26 March 2013 17:18, roger riggs <rog...@or...> wrote: > Hi, > > ok, I saw some possible confusion between weekOfYear and WeekBasedYear. > > The updated webrev is: > http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ > > I'd like to commit and move on to the changes to DateTimeFormatter. > > Roger > > > > On 3/26/2013 11:53 AM, Stephen Colebourne wrote: >> On 26 March 2013 15:00, roger riggs <rog...@or...> wrote: >>> References to "yearOfWeekBasedYear " should be just "weekBasedYear". >>> Notably, this affects the public method name. >>> >>> If we are to keep both the current weekBasedYear (with week 0) and >>> the WeekBasedYear that has each week in only a single year then the >>> other week based fields need distinguished names. >>> >>> We can remove the current weekBasedYear and remove some possible >>> confusion but you've said it is useful. >> The old field is week-of-year, the new fields are >> week-of-week-based-year and week-based-year. Each name is unique, so I >> don't see a problem here. >> >> Stephen >> > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: roger r. <rog...@or...> - 2013-03-26 17:18:45
|
Hi, ok, I saw some possible confusion between weekOfYear and WeekBasedYear. The updated webrev is: http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ I'd like to commit and move on to the changes to DateTimeFormatter. Roger On 3/26/2013 11:53 AM, Stephen Colebourne wrote: > On 26 March 2013 15:00, roger riggs <rog...@or...> wrote: >> References to "yearOfWeekBasedYear " should be just "weekBasedYear". >> Notably, this affects the public method name. >> >> If we are to keep both the current weekBasedYear (with week 0) and >> the WeekBasedYear that has each week in only a single year then the >> other week based fields need distinguished names. >> >> We can remove the current weekBasedYear and remove some possible >> confusion but you've said it is useful. > The old field is week-of-year, the new fields are > week-of-week-based-year and week-based-year. Each name is unique, so I > don't see a problem here. > > Stephen > |
From: Stephen C. <sco...@jo...> - 2013-03-26 15:53:44
|
On 26 March 2013 15:00, roger riggs <rog...@or...> wrote: > References to "yearOfWeekBasedYear " should be just "weekBasedYear". > Notably, this affects the public method name. > > If we are to keep both the current weekBasedYear (with week 0) and > the WeekBasedYear that has each week in only a single year then the > other week based fields need distinguished names. > > We can remove the current weekBasedYear and remove some possible > confusion but you've said it is useful. The old field is week-of-year, the new fields are week-of-week-based-year and week-based-year. Each name is unique, so I don't see a problem here. Stephen |
From: roger r. <rog...@or...> - 2013-03-26 15:00:16
|
Hi Stephen, On 3/26/2013 8:57 AM, Stephen Colebourne wrote: > "The rules for addition add the number of week-based-years to the > existing value for the week-based-year field. If the resulting > week-based-year only has 52 weeks, then the date will be in week 1 of > the following week-based-year." > > This isn't the right behaviour (or is a bad description). Addition > should retain the value of the week and day-of-week. The special case > is if the base week has the value 53 but the result of the calculation > is a week-based-year which has only 52 weeks. In that case, the result > would indeed be in the first week of the following year. Yes, this obsolete and is updated to keep the week in the target year. "The rules for addition add the number of week-based-years to the existing value * for the week-based-year field retaining the week-of-week-based-year * and day-of-week, unless the week number it too large for the target year. * In that case, the week is set to the last week of the year * with the same day-of-week." > > References to "yearOfWeekBasedYear " should be just "weekBasedYear". > Notably, this affects the public method name. If we are to keep both the current weekBasedYear (with week 0) and the WeekBasedYear that has each week in only a single year then the other week based fields need distinguished names. We can remove the current weekBasedYear and remove some possible confusion but you've said it is useful. > > Comment text "This unit is an immutable and thread-safe singleton." > should be "This field is an immutable and thread-safe singleton." fixed. > > The comment text "week based year" should be dash linked "week-based-year". fixed. > > The range of week-based-year is not necessarily the same as the range > of year. It needs to be confirmed. Range of WeekBaseYear might be one less or one greater than the underlying year depending on the start and min. > > Comment text "This represents concept of the count" should be This > represents the concept of the count. fixed > > My skim of the algorithms looks OK Thanks, Roger > > thanks > Stephen > > > On 26 March 2013 01:23, Roger Riggs <Rog...@or...> wrote: >> Please Review: >> >> Issue 64 notes that to correctly support CLDR "Y" and "w", new fields >> are needed that operate correctly for Week and Year of WeekBasedYear. >> This webrev implements additions fields in WeekFields. >> >> http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ >> >> An additional factory for creating Dates from YearOfWeekBasedYear, >> WeekOfWeekBasedYear and DayOfWeek plus a chronology. >> >> Roger >> >> >> ------------------------------------------------------------------------------ >> Own the Future-Intel® Level Up Game Demo Contest 2013 >> Rise to greatness in Intel's independent game demo contest. >> Compete for recognition, cash, and the chance to get your game >> on Steam. $5K grand prize plus 10 genre and skill prizes. >> Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |
From: Stephen C. <sco...@jo...> - 2013-03-26 12:57:30
|
"The rules for addition add the number of week-based-years to the existing value for the week-based-year field. If the resulting week-based-year only has 52 weeks, then the date will be in week 1 of the following week-based-year." This isn't the right behaviour (or is a bad description). Addition should retain the value of the week and day-of-week. The special case is if the base week has the value 53 but the result of the calculation is a week-based-year which has only 52 weeks. In that case, the result would indeed be in the first week of the following year. References to "yearOfWeekBasedYear " should be just "weekBasedYear". Notably, this affects the public method name. Comment text "This unit is an immutable and thread-safe singleton." should be "This field is an immutable and thread-safe singleton." The comment text "week based year" should be dash linked "week-based-year". The range of week-based-year is not necessarily the same as the range of year. It needs to be confirmed. Comment text "This represents concept of the count" should be This represents the concept of the count. My skim of the algorithms looks OK thanks Stephen On 26 March 2013 01:23, Roger Riggs <Rog...@or...> wrote: > Please Review: > > Issue 64 notes that to correctly support CLDR "Y" and "w", new fields > are needed that operate correctly for Week and Year of WeekBasedYear. > This webrev implements additions fields in WeekFields. > > http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ > > An additional factory for creating Dates from YearOfWeekBasedYear, > WeekOfWeekBasedYear and DayOfWeek plus a chronology. > > Roger > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: Roger R. <Roger.Riggs@Oracle.com> - 2013-03-26 01:23:29
|
Please Review: Issue 64 notes that to correctly support CLDR "Y" and "w", new fields are needed that operate correctly for Week and Year of WeekBasedYear. This webrev implements additions fields in WeekFields. http://cr.openjdk.java.net/~rriggs/webrev-WeekBasedYear-64/ An additional factory for creating Dates from YearOfWeekBasedYear, WeekOfWeekBasedYear and DayOfWeek plus a chronology. Roger |
From: Stephen C. <sco...@jo...> - 2013-03-24 17:44:55
|
Raised as bug https://github.com/ThreeTen/threeten/issues/290 Stephen On 24 March 2013 12:46, Mark Brouwer <mar...@ma...> wrote: > On 3/24/13 1:06 AM, Mark Brouwer wrote: > >> In case the subtraction of the nanos of t2 from t1 is negative 1 second >> needs to be added to the whole number of seconds for the interval >> between the 2 Temporal arguments. > > Probably needles to say that if t2 is before t1 that it should be the > other way around. In case the subtraction of the nanos of t2 from t1 is > positive 1 second needs to be subtracted from the whole number of > seconds for the interval between the 2 Temporal arguments. > > Regards, > -- > Mark Brouwer > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Mark B. <mar...@ma...> - 2013-03-24 12:47:05
|
On 3/24/13 1:06 AM, Mark Brouwer wrote: > In case the subtraction of the nanos of t2 from t1 is negative 1 second > needs to be added to the whole number of seconds for the interval > between the 2 Temporal arguments. Probably needles to say that if t2 is before t1 that it should be the other way around. In case the subtraction of the nanos of t2 from t1 is positive 1 second needs to be subtracted from the whole number of seconds for the interval between the 2 Temporal arguments. Regards, -- Mark Brouwer |
From: Mark B. <mar...@ma...> - 2013-03-24 00:20:42
|
Hi, I'm playing around with the java.time API and while I was replacing java.util.Date with java.time.LocalDateTime I noticed that some of my unit tests failed, but not always. Turned out that Duration.between() didn't calculate the correct duration for a time interval when the number of nanoseconds for the endExclusive argument is less than the number of nanoseconds of the startInclusive argument. In such a situation the duration is always 1 second off. See test case below. LocalDateTime t1 = LocalDateTime.parse("2013-03-24T00:44:31.565"); LocalDateTime t2 = LocalDateTime.parse("2013-03-24T00:44:33.065"); System.out.println(t1); System.out.println(t2); System.out.println(Duration.between(t1, t2)); Result is: 2013-03-24T00:44:31.565 2013-03-24T00:44:33.065 PT0.5S (should have been PT1.5S) In case the subtraction of the nanos of t2 from t1 is negative 1 second needs to be added to the whole number of seconds for the interval between the 2 Temporal arguments. BTW it would be great if the src.zip file would contain the sources for the reference implementation of JSR-310, as that would help a lot when working with the regular JDK 8 builds. Regards, -- Mark Brouwer |
From: Chris H. <ch...@xe...> - 2013-03-22 15:38:34
|
Thanks. I use Ubuntu, so the build works fine. I can now start looking at it, rather than using the github build of threeten Chris On 22 March 2013 15:10, Stephen Colebourne <sco...@jo...> wrote: > There should be instructions under Adopt OpenJDK, although I don't > know exactly where. > Stephen > > > On 22 March 2013 15:04, Chris Hudson <ch...@xe...> wrote: >> I want to use the route which will be of more use. That seems to be >> the open jdk 8 route, so will go from there >> >> Thanks >> >> Chris >> >> On 22 March 2013 15:00, Stephen Colebourne <sco...@jo...> wrote: >>> You should work from one of two base points. >>> >>> The "live" JDK 1.8 code is in Mercurial at >>> hg.openjdk.java.net/threeten/threeten (and particularly the jdk repo >>> beneath). Building this involves building the whole of OpenJDK which >>> can be a complex process especially on Windows. If you want to go down >>> this route we can try to guide you. >>> >>> The "backport" code is in GitHub at >>> https://github.com/ThreeTen/threetenbp . This should build simply and >>> without issues using maven. However, it represents a forked and not up >>> to date version of ThreeTen (equivalent to about 4 weeks ago). >>> >>> Neither option is exactly perfect for your needs, however the backport >>> will be the simplest one to build (or just use the jars in maven >>> central http://search.maven.org/#artifactdetails|org.threeten|threetenbp|0.8.1|jar) >>> >>> Hope this helps >>> Stephen >>> >>> >>> >>> On 22 March 2013 14:39, Chris Hudson <ch...@xe...> wrote: >>>> I am trying to get on board with the Threeten project. >>>> >>>> I have forked the original repository and cloned my local version. >>>> I am using openJDK 1.7. I have tried openJDK 1.8-ea, but get the same thing >>>> >>>> I am building on Ubuntu 12.10 >>>> >>>> When I try to run the ant build I am getting the following output: >>>> >>>> [testng] =============================================== >>>> [testng] Ant test >>>> [testng] Tests run: 1537, Failures: 0, Skips: 0 >>>> [testng] =============================================== >>>> [testng] >>>> [testng] >>>> [testng] =============================================== >>>> [testng] Ant suite >>>> [testng] Total tests run: 1537, Failures: 0, Skips: 0 >>>> [testng] =============================================== >>>> [testng] >>>> >>>> check-sigtest-downloaded: >>>> >>>> download-sigtest: >>>> >>>> tdtck: >>>> >>>> run-sigtest: >>>> [test-sigtest-task] See log st_report.txt for more details. >>>> >>>> BUILD FAILED >>>> /home/chris/Projects/threeten/build.xml:272: STATUS:Error.Can not find >>>> or read signature file(s): build/test/jsr310.sig >>>> >>>> >>>> All I want to do is get a starting position to work with, but seem to >>>> be struggling. >>>> >>>> Any help? >>>> >>>> Thanks >>>> >>>> Chris Hudson >>>> >>>> ------------------------------------------------------------------------------ >>>> Everyone hates slow websites. So do we. >>>> Make your web apps faster with AppDynamics >>>> Download AppDynamics Lite for free today: >>>> http://p.sf.net/sfu/appdyn_d2d_mar >>>> _______________________________________________ >>>> threeten-develop mailing list >>>> thr...@li... >>>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_mar >>> _______________________________________________ >>> threeten-develop mailing list >>> thr...@li... >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2013-03-22 15:11:14
|
There should be instructions under Adopt OpenJDK, although I don't know exactly where. Stephen On 22 March 2013 15:04, Chris Hudson <ch...@xe...> wrote: > I want to use the route which will be of more use. That seems to be > the open jdk 8 route, so will go from there > > Thanks > > Chris > > On 22 March 2013 15:00, Stephen Colebourne <sco...@jo...> wrote: >> You should work from one of two base points. >> >> The "live" JDK 1.8 code is in Mercurial at >> hg.openjdk.java.net/threeten/threeten (and particularly the jdk repo >> beneath). Building this involves building the whole of OpenJDK which >> can be a complex process especially on Windows. If you want to go down >> this route we can try to guide you. >> >> The "backport" code is in GitHub at >> https://github.com/ThreeTen/threetenbp . This should build simply and >> without issues using maven. However, it represents a forked and not up >> to date version of ThreeTen (equivalent to about 4 weeks ago). >> >> Neither option is exactly perfect for your needs, however the backport >> will be the simplest one to build (or just use the jars in maven >> central http://search.maven.org/#artifactdetails|org.threeten|threetenbp|0.8.1|jar) >> >> Hope this helps >> Stephen >> >> >> >> On 22 March 2013 14:39, Chris Hudson <ch...@xe...> wrote: >>> I am trying to get on board with the Threeten project. >>> >>> I have forked the original repository and cloned my local version. >>> I am using openJDK 1.7. I have tried openJDK 1.8-ea, but get the same thing >>> >>> I am building on Ubuntu 12.10 >>> >>> When I try to run the ant build I am getting the following output: >>> >>> [testng] =============================================== >>> [testng] Ant test >>> [testng] Tests run: 1537, Failures: 0, Skips: 0 >>> [testng] =============================================== >>> [testng] >>> [testng] >>> [testng] =============================================== >>> [testng] Ant suite >>> [testng] Total tests run: 1537, Failures: 0, Skips: 0 >>> [testng] =============================================== >>> [testng] >>> >>> check-sigtest-downloaded: >>> >>> download-sigtest: >>> >>> tdtck: >>> >>> run-sigtest: >>> [test-sigtest-task] See log st_report.txt for more details. >>> >>> BUILD FAILED >>> /home/chris/Projects/threeten/build.xml:272: STATUS:Error.Can not find >>> or read signature file(s): build/test/jsr310.sig >>> >>> >>> All I want to do is get a starting position to work with, but seem to >>> be struggling. >>> >>> Any help? >>> >>> Thanks >>> >>> Chris Hudson >>> >>> ------------------------------------------------------------------------------ >>> Everyone hates slow websites. So do we. >>> Make your web apps faster with AppDynamics >>> Download AppDynamics Lite for free today: >>> http://p.sf.net/sfu/appdyn_d2d_mar >>> _______________________________________________ >>> threeten-develop mailing list >>> thr...@li... >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Chris H. <ch...@xe...> - 2013-03-22 15:05:08
|
I want to use the route which will be of more use. That seems to be the open jdk 8 route, so will go from there Thanks Chris On 22 March 2013 15:00, Stephen Colebourne <sco...@jo...> wrote: > You should work from one of two base points. > > The "live" JDK 1.8 code is in Mercurial at > hg.openjdk.java.net/threeten/threeten (and particularly the jdk repo > beneath). Building this involves building the whole of OpenJDK which > can be a complex process especially on Windows. If you want to go down > this route we can try to guide you. > > The "backport" code is in GitHub at > https://github.com/ThreeTen/threetenbp . This should build simply and > without issues using maven. However, it represents a forked and not up > to date version of ThreeTen (equivalent to about 4 weeks ago). > > Neither option is exactly perfect for your needs, however the backport > will be the simplest one to build (or just use the jars in maven > central http://search.maven.org/#artifactdetails|org.threeten|threetenbp|0.8.1|jar) > > Hope this helps > Stephen > > > > On 22 March 2013 14:39, Chris Hudson <ch...@xe...> wrote: >> I am trying to get on board with the Threeten project. >> >> I have forked the original repository and cloned my local version. >> I am using openJDK 1.7. I have tried openJDK 1.8-ea, but get the same thing >> >> I am building on Ubuntu 12.10 >> >> When I try to run the ant build I am getting the following output: >> >> [testng] =============================================== >> [testng] Ant test >> [testng] Tests run: 1537, Failures: 0, Skips: 0 >> [testng] =============================================== >> [testng] >> [testng] >> [testng] =============================================== >> [testng] Ant suite >> [testng] Total tests run: 1537, Failures: 0, Skips: 0 >> [testng] =============================================== >> [testng] >> >> check-sigtest-downloaded: >> >> download-sigtest: >> >> tdtck: >> >> run-sigtest: >> [test-sigtest-task] See log st_report.txt for more details. >> >> BUILD FAILED >> /home/chris/Projects/threeten/build.xml:272: STATUS:Error.Can not find >> or read signature file(s): build/test/jsr310.sig >> >> >> All I want to do is get a starting position to work with, but seem to >> be struggling. >> >> Any help? >> >> Thanks >> >> Chris Hudson >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_mar >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2013-03-22 15:00:30
|
You should work from one of two base points. The "live" JDK 1.8 code is in Mercurial at hg.openjdk.java.net/threeten/threeten (and particularly the jdk repo beneath). Building this involves building the whole of OpenJDK which can be a complex process especially on Windows. If you want to go down this route we can try to guide you. The "backport" code is in GitHub at https://github.com/ThreeTen/threetenbp . This should build simply and without issues using maven. However, it represents a forked and not up to date version of ThreeTen (equivalent to about 4 weeks ago). Neither option is exactly perfect for your needs, however the backport will be the simplest one to build (or just use the jars in maven central http://search.maven.org/#artifactdetails|org.threeten|threetenbp|0.8.1|jar) Hope this helps Stephen On 22 March 2013 14:39, Chris Hudson <ch...@xe...> wrote: > I am trying to get on board with the Threeten project. > > I have forked the original repository and cloned my local version. > I am using openJDK 1.7. I have tried openJDK 1.8-ea, but get the same thing > > I am building on Ubuntu 12.10 > > When I try to run the ant build I am getting the following output: > > [testng] =============================================== > [testng] Ant test > [testng] Tests run: 1537, Failures: 0, Skips: 0 > [testng] =============================================== > [testng] > [testng] > [testng] =============================================== > [testng] Ant suite > [testng] Total tests run: 1537, Failures: 0, Skips: 0 > [testng] =============================================== > [testng] > > check-sigtest-downloaded: > > download-sigtest: > > tdtck: > > run-sigtest: > [test-sigtest-task] See log st_report.txt for more details. > > BUILD FAILED > /home/chris/Projects/threeten/build.xml:272: STATUS:Error.Can not find > or read signature file(s): build/test/jsr310.sig > > > All I want to do is get a starting position to work with, but seem to > be struggling. > > Any help? > > Thanks > > Chris Hudson > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_mar > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Chris H. <ch...@xe...> - 2013-03-22 14:39:51
|
I am trying to get on board with the Threeten project. I have forked the original repository and cloned my local version. I am using openJDK 1.7. I have tried openJDK 1.8-ea, but get the same thing I am building on Ubuntu 12.10 When I try to run the ant build I am getting the following output: [testng] =============================================== [testng] Ant test [testng] Tests run: 1537, Failures: 0, Skips: 0 [testng] =============================================== [testng] [testng] [testng] =============================================== [testng] Ant suite [testng] Total tests run: 1537, Failures: 0, Skips: 0 [testng] =============================================== [testng] check-sigtest-downloaded: download-sigtest: tdtck: run-sigtest: [test-sigtest-task] See log st_report.txt for more details. BUILD FAILED /home/chris/Projects/threeten/build.xml:272: STATUS:Error.Can not find or read signature file(s): build/test/jsr310.sig All I want to do is get a starting position to work with, but seem to be struggling. Any help? Thanks Chris Hudson |
From: roger r. <rog...@or...> - 2013-03-14 19:35:46
|
Please review updates to address issues #283 and #279. #283: Serialization of Chronology #279 Inconsistent serialization for ISO chronology Cleaned up serialization for all Chronologies and added tests. Subclasses are enabled (as is ISOChronology) to use the Ser mechanism of Chronology. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-serialization-283/ Thanks, Roger |