From roger.riggs at oracle.com Tue Oct 1 14:53:17 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 01 Oct 2013 17:53:17 -0400 Subject: [threeten-dev] static methods in interfaces: TemporalAdjuster and TemporalQuery Message-ID: <524B444D.1090901@oracle.com> Hi, As proposed in https://github.com/ThreeTen/threeten/issues/340 and in JBS: https://bugs.openjdk.java.net/browse/JDK-8025722 "The static methods on TemporalAdjuster and TemporalQuery feel slightly misplaced after using them for a few months. While they make discovery easier, they add significant weight to the basic interface. Using separate static classes for methods which are an extensible set feels more appropriate now. " The javadoc is: http://cr.openjdk.java.net/~rriggs/javadoc-temporal-statics-8025722/ The webrev: http://cr.openjdk.java.net/~rriggs/webrev-temporal-statics-8025722/ Please comment, Roger p.s. a regular core-libs Review will be needed also. From scolebourne at joda.org Wed Oct 2 00:50:35 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 2 Oct 2013 08:50:35 +0100 Subject: [threeten-dev] static methods in interfaces: TemporalAdjuster and TemporalQuery In-Reply-To: <524B444D.1090901@oracle.com> References: <524B444D.1090901@oracle.com> Message-ID: Looks good to me. This change also aids separation of the Temporal layer of interfaces. Stephen On 1 October 2013 22:53, roger riggs wrote: > Hi, > > As proposed in https://github.com/ThreeTen/threeten/issues/340 > and in JBS: https://bugs.openjdk.java.net/browse/JDK-8025722 > > "The static methods on TemporalAdjuster and TemporalQuery feel slightly > misplaced after using them for a few months. While they make discovery > easier, they add significant weight to the basic interface. Using separate > static classes for methods which are an extensible set feels more > appropriate now. " > > The javadoc is: > http://cr.openjdk.java.net/~rriggs/javadoc-temporal-statics-8025722/ > > The webrev: > http://cr.openjdk.java.net/~rriggs/webrev-temporal-statics-8025722/ > > Please comment, Roger > > p.s. a regular core-libs Review will be needed also. > From sharon.zakhour at oracle.com Wed Oct 2 11:23:08 2013 From: sharon.zakhour at oracle.com (Sharon Zakhour) Date: Wed, 02 Oct 2013 11:23:08 -0700 Subject: [threeten-dev] New Date Time tutorial Message-ID: <524C648C.1090700@oracle.com> Just to let you know that we recently released a new trail, Date-Time API , in the Java Tutorial that covers the java.time packages coming in JDK 8. Thanks! From scolebourne at joda.org Wed Oct 2 18:24:17 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Thu, 3 Oct 2013 02:24:17 +0100 Subject: [threeten-dev] New Date Time tutorial In-Reply-To: <524C648C.1090700@oracle.com> References: <524C648C.1090700@oracle.com> Message-ID: Just a public Thank You to Sharon for working on this great guide ;-) Stephen On 2 October 2013 19:23, Sharon Zakhour wrote: > Just to let you know that we recently released a new trail, Date-Time API > , in the Java > Tutorial that covers the java.time packages coming in JDK 8. > > Thanks! From roger.riggs at oracle.com Mon Oct 7 13:13:36 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 07 Oct 2013 16:13:36 -0400 Subject: [threeten-dev] Changing Chronology to an interface and AbstractChronology Message-ID: <525315F0.2040101@oracle.com> Changing Chronology to an interface is a positive step as suggested by #341 and JBS https://jbs.oracle.com/bugs/browse/JDK-8025719. The suggsted fix includes the definition AbstractChronology and proposes cleanup of the subclasses based on the generic type. This feature was not present in the proposed patch. Has the suggestion been withdrawn? Thank, Roger [1] webrev: http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ From scolebourne at joda.org Mon Oct 7 15:42:36 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 7 Oct 2013 23:42:36 +0100 Subject: [threeten-dev] Changing Chronology to an interface and AbstractChronology In-Reply-To: <525315F0.2040101@oracle.com> References: <525315F0.2040101@oracle.com> Message-ID: The webrev looks good. I think that the extended behaviour would be a good extension. I didn't implement it back then as I wasn't certain that the change to interface was going to happen. Stephen On 7 October 2013 21:13, roger riggs wrote: > Changing Chronology to an interface is a positive step as suggested by #341 > and JBS https://jbs.oracle.com/bugs/browse/JDK-8025719. > > The suggsted fix includes the definition AbstractChronology ChronoLocalDate> > and proposes cleanup of the subclasses based on the generic type. > This feature was not present in the proposed patch. > Has the suggestion been withdrawn? > > Thank, Roger > [1] webrev: > http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ > From roger.riggs at oracle.com Tue Oct 8 09:29:29 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 08 Oct 2013 12:29:29 -0400 Subject: [threeten-dev] Changing Chronology to an interface and AbstractChronology In-Reply-To: References: <525315F0.2040101@oracle.com> Message-ID: <525432E9.5080503@oracle.com> Hi Stephen, By applying the proposed change to AbstractChronology, the JapaneseDate Javadoc becomes much less informative and complete, the only references to some methods, such as dateNow(), are in the tiny list of methods inherited from the supertype. AbstractChronology duplicates the implementations of the default methods of the interfaces (though they could just delegate). Javadoc: http://cr.openjdk.java.net/~rriggs/javadoc-chrono-interface-8025719/ webrev: http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ The negative effects of adding generics to AbstractChronology seem to outweigh the benefits. Suggestions welcome, Roger On 10/7/2013 6:42 PM, Stephen Colebourne wrote: > The webrev looks good. > > I think that the extended behaviour would be a good extension. I > didn't implement it back then as I wasn't certain that the change to > interface was going to happen. > > Stephen > > > On 7 October 2013 21:13, roger riggs wrote: >> Changing Chronology to an interface is a positive step as suggested by #341 >> and JBS https://jbs.oracle.com/bugs/browse/JDK-8025719. >> >> The suggsted fix includes the definition AbstractChronology> ChronoLocalDate> >> and proposes cleanup of the subclasses based on the generic type. >> This feature was not present in the proposed patch. >> Has the suggestion been withdrawn? >> >> Thank, Roger >> [1] webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ >> From scolebourne at joda.org Tue Oct 8 10:19:59 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 8 Oct 2013 18:19:59 +0100 Subject: [threeten-dev] Changing Chronology to an interface and AbstractChronology In-Reply-To: <525432E9.5080503@oracle.com> References: <525315F0.2040101@oracle.com> <525432E9.5080503@oracle.com> Message-ID: Personally I think that the IDE is where most people discover the methods, and that would be unaffected.. That said, I see your point. I think given the timescale, I'd rather ensure the interface change goes in. If you are uncomfortable with it I suggest leaving the generic methods part out. BTW, we cannot fix this later. The effect is small though, as it just means that the few implementors of chronology will have a little more work to do to give their users the best API. Beyond that I see no harm. Stephen On 8 October 2013 17:29, roger riggs wrote: > Hi Stephen, > > By applying the proposed change to AbstractChronology, the JapaneseDate > Javadoc > becomes much less informative and complete, the only references to some > methods, > such as dateNow(), are in the tiny list of methods inherited from the > supertype. > > AbstractChronology duplicates the implementations of the default > methods of the interfaces (though they could just delegate). > > Javadoc: > http://cr.openjdk.java.net/~rriggs/javadoc-chrono-interface-8025719/ > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ > > The negative effects of adding generics to AbstractChronology seem to > outweigh > the benefits. > > Suggestions welcome, > > Roger > > > > > > > On 10/7/2013 6:42 PM, Stephen Colebourne wrote: >> >> The webrev looks good. >> >> I think that the extended behaviour would be a good extension. I >> didn't implement it back then as I wasn't certain that the change to >> interface was going to happen. >> >> Stephen >> >> >> On 7 October 2013 21:13, roger riggs wrote: >>> >>> Changing Chronology to an interface is a positive step as suggested by >>> #341 >>> and JBS https://jbs.oracle.com/bugs/browse/JDK-8025719. >>> >>> The suggsted fix includes the definition AbstractChronology>> ChronoLocalDate> >>> and proposes cleanup of the subclasses based on the generic type. >>> This feature was not present in the proposed patch. >>> Has the suggestion been withdrawn? >>> >>> Thank, Roger >>> [1] webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ >>> > From roger.riggs at oracle.com Tue Oct 8 12:26:21 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 08 Oct 2013 15:26:21 -0400 Subject: [threeten-dev] Changing Chronology to an interface and AbstractChronology In-Reply-To: References: <525315F0.2040101@oracle.com> <525432E9.5080503@oracle.com> Message-ID: <52545C5D.9090303@oracle.com> Hi Stephen, The basic split of Chronology is fine. I'll proceed with that unless there is some additional value of the generics on AbstractChronology would be missed. Roger On 10/8/2013 1:19 PM, Stephen Colebourne wrote: > Personally I think that the IDE is where most people discover the > methods, and that would be unaffected.. That said, I see your point. > > I think given the timescale, I'd rather ensure the interface change > goes in. If you are uncomfortable with it I suggest leaving the > generic methods part out. > > BTW, we cannot fix this later. The effect is small though, as it just > means that the few implementors of chronology will have a little more > work to do to give their users the best API. Beyond that I see no > harm. > > Stephen > > > > On 8 October 2013 17:29, roger riggs wrote: >> Hi Stephen, >> >> By applying the proposed change to AbstractChronology, the JapaneseDate >> Javadoc >> becomes much less informative and complete, the only references to some >> methods, >> such as dateNow(), are in the tiny list of methods inherited from the >> supertype. >> >> AbstractChronology duplicates the implementations of the default >> methods of the interfaces (though they could just delegate). >> >> Javadoc: >> http://cr.openjdk.java.net/~rriggs/javadoc-chrono-interface-8025719/ >> >> webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ >> >> The negative effects of adding generics to AbstractChronology seem to >> outweigh >> the benefits. >> >> Suggestions welcome, >> >> Roger >> >> >> >> >> >> >> On 10/7/2013 6:42 PM, Stephen Colebourne wrote: >>> The webrev looks good. >>> >>> I think that the extended behaviour would be a good extension. I >>> didn't implement it back then as I wasn't certain that the change to >>> interface was going to happen. >>> >>> Stephen >>> >>> >>> On 7 October 2013 21:13, roger riggs wrote: >>>> Changing Chronology to an interface is a positive step as suggested by >>>> #341 >>>> and JBS https://jbs.oracle.com/bugs/browse/JDK-8025719. >>>> >>>> The suggsted fix includes the definition AbstractChronology>>> ChronoLocalDate> >>>> and proposes cleanup of the subclasses based on the generic type. >>>> This feature was not present in the proposed patch. >>>> Has the suggestion been withdrawn? >>>> >>>> Thank, Roger >>>> [1] webrev: >>>> http://cr.openjdk.java.net/~rriggs/webrev-chrono-interface-8025719/ >>>> From scolebourne at joda.org Fri Oct 18 13:58:26 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Fri, 18 Oct 2013 21:58:26 +0100 Subject: [threeten-dev] Removing ZoneId HST/MST/EST Message-ID: As per this bug report: https://bugs.openjdk.java.net/browse/JDK-8026842 I am proposing to remove these three IDs from ZoneId in JDK 8: HST (Hawaii) EST (US Eastern standard) MST (US Mountain standard) They are the only confusing "short" 3 letter IDs in the TZDB (other short IDs are not confusing in the same way). These three IDs have a long a horrid history where they once included daylight savings time and now do not, requiring a special JDK flag. These IDs have been marked as deprecated in TimeZone for a very long time. http://docs.oracle.com/javase/7/docs/api/java/util/TimeZone.html The correct replacements are: EST - America/New_York MST - America/Denver HST - Pacific/Honolulu Note that these IDs were never supported: EDT (Eastern daylight time), MDT (Mountain daylight), PST (Pacific standard), PDT (Pacific daylight), CST (Central standard), CDT (Central daylight) which emphasises the weird nature of the three proposed for deletion, and the potential for user bugs (by assuming PST must exist if EST does). Note that TimeZone will continue to correctly work with these three IDs (for backwards compatibility). If you feel strongly about these 3 IDs, speak now! Stephen From xueming.shen at oracle.com Mon Oct 21 21:16:58 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Mon, 21 Oct 2013 21:16:58 -0700 Subject: [threeten-dev] JDK-8024267 Stop using LMT for time-zones Message-ID: <5265FC3A.7050800@oracle.com> Hi Stephen, The current j.u.TimeZone implementation DOES use LMT. If the LMT is defined/used cross the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example the offset for Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the LMT 10.34.36. Yes, if the LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ. So if the LMT is removed from the JSR310 zdt, inevitably we are going to have problem to handle those date/time that fall into the period that uses LMT (after 1900.11) when converting between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can remove the LMT from the j.u.TimeZone for obvious compatibility reason. Sure, arguably because the j.u.Timezone 1900.1.1 cutoff, we are having this problem already for date/time before the 1900 cutoff, but the removal is just to make thing worse. As you suggested in the bug report, the problem is what to replace the LMT with. Honestly I don't think any proposed alternative is better than the LMT (basically it's the tzdb's solution for this unsolvable problem, what offset to use for that particular zone before any timezone even get defined for that area). And what you're proposing basically is to fork the tzdb for that part of date/time, replacing the location-based LMT with your own algorithm, for non-convincing reason. Yes, the LMT is not ideal, but "to calculate and use a longest standard used between 1970 and 2010" really does not make thing any better. While it's true that it's "simple and deterministic", but it's still not correct at all for that period of time. The cost is to fork the standard tzdb data and walk away from our "standard based" design principal for timezone data. I agree the choice of the "location" for some particular zones might not be ideal/correct/reasonable, but I don't think this is a big enough issue for the cost of forking from the tzdb data for Java date/time. I would suggest to simply keep the LMT asis, and close this RFE/bug, at least for now. Thanks, Sherman From masayoshi.okutsu at oracle.com Mon Oct 21 22:33:10 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Tue, 22 Oct 2013 14:33:10 +0900 Subject: [threeten-dev] JDK-8024267 Stop using LMT for time-zones In-Reply-To: <5265FC3A.7050800@oracle.com> References: <5265FC3A.7050800@oracle.com> Message-ID: <52660E16.4020402@oracle.com> +1 Masayoshi On 10/22/2013 1:16 PM, Xueming Shen wrote: > Hi Stephen, > > The current j.u.TimeZone implementation DOES use LMT. If the LMT is > defined/used cross > the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example > the offset for > Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the LMT > 10.34.36. Yes, if the > LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ. > > So if the LMT is removed from the JSR310 zdt, inevitably we are going > to have problem to > handle those date/time that fall into the period that uses LMT (after > 1900.11) when converting > between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can > remove the LMT > from the j.u.TimeZone for obvious compatibility reason. Sure, arguably > because the > j.u.Timezone 1900.1.1 cutoff, we are having this problem already for > date/time before the > 1900 cutoff, but the removal is just to make thing worse. > > As you suggested in the bug report, the problem is what to replace the > LMT with. Honestly > I don't think any proposed alternative is better than the LMT > (basically it's the tzdb's solution > for this unsolvable problem, what offset to use for that particular > zone before any timezone > even get defined for that area). And what you're proposing basically > is to fork the tzdb for > that part of date/time, replacing the location-based LMT with your own > algorithm, for > non-convincing reason. Yes, the LMT is not ideal, but "to calculate > and use a longest standard > used between 1970 and 2010" really does not make thing any better. > While it's true that it's > "simple and deterministic", but it's still not correct at all for that > period of time. The cost is to > fork the standard tzdb data and walk away from our "standard based" > design principal for > timezone data. I agree the choice of the "location" for some > particular zones might not be > ideal/correct/reasonable, but I don't think this is a big enough issue > for the cost of forking > from the tzdb data for Java date/time. > > I would suggest to simply keep the LMT asis, and close this RFE/bug, > at least for now. > > Thanks, > Sherman > > > From roger.riggs at oracle.com Tue Oct 22 07:26:57 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 22 Oct 2013 10:26:57 -0400 Subject: [threeten-dev] JDK-8024267 Stop using LMT for time-zones In-Reply-To: <5265FC3A.7050800@oracle.com> References: <5265FC3A.7050800@oracle.com> Message-ID: <52668B31.1060407@oracle.com> Hi Sherman, Thanks for digging into the details and providing a sound rationale. I agree with the conclusion. Thanks, Roger On 10/22/2013 12:16 AM, Xueming Shen wrote: > Hi Stephen, > > The current j.u.TimeZone implementation DOES use LMT. If the LMT is > defined/used cross > the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example > the offset for > Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the LMT > 10.34.36. Yes, if the > LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ. > > So if the LMT is removed from the JSR310 zdt, inevitably we are going > to have problem to > handle those date/time that fall into the period that uses LMT (after > 1900.11) when converting > between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can > remove the LMT > from the j.u.TimeZone for obvious compatibility reason. Sure, arguably > because the > j.u.Timezone 1900.1.1 cutoff, we are having this problem already for > date/time before the > 1900 cutoff, but the removal is just to make thing worse. > > As you suggested in the bug report, the problem is what to replace the > LMT with. Honestly > I don't think any proposed alternative is better than the LMT > (basically it's the tzdb's solution > for this unsolvable problem, what offset to use for that particular > zone before any timezone > even get defined for that area). And what you're proposing basically > is to fork the tzdb for > that part of date/time, replacing the location-based LMT with your own > algorithm, for > non-convincing reason. Yes, the LMT is not ideal, but "to calculate > and use a longest standard > used between 1970 and 2010" really does not make thing any better. > While it's true that it's > "simple and deterministic", but it's still not correct at all for that > period of time. The cost is to > fork the standard tzdb data and walk away from our "standard based" > design principal for > timezone data. I agree the choice of the "location" for some > particular zones might not be > ideal/correct/reasonable, but I don't think this is a big enough issue > for the cost of forking > from the tzdb data for Java date/time. > > I would suggest to simply keep the LMT asis, and close this RFE/bug, > at least for now. > > Thanks, > Sherman > > > From scolebourne at joda.org Tue Oct 22 08:12:02 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 22 Oct 2013 16:12:02 +0100 Subject: [threeten-dev] JDK-8024267 Stop using LMT for time-zones In-Reply-To: <5265FC3A.7050800@oracle.com> References: <5265FC3A.7050800@oracle.com> Message-ID: The Theory file in TZDB defines what LMT is and how it will be treated https://github.com/eggert/tz/blob/master/Theory#L352 "In short, many, perhaps most, of the tz database's pre-1970 and future time stamps are either wrong or misleading. Any attempt to pass the tz database off as the definition of time should be unacceptable to anybody who cares about the facts. In particular, the tz database's LMT offsets should not be considered meaningful, and should not prompt creation of zones merely because two locations differ in LMT or transitioned to standard time at different dates." What this means in practice is that LMT values have been and will be changed on a whim, with absolutely no rationale for the change. In practical terms, this means that a user of JSR-310 who creates a ZonedDateTime representing a date in 1800 will see an LMT offset measured in seconds, such as +01:32:29. When the TZDB is updated, this offset may change, and there will be no valid rationale for the change. That randomness of change will be a major cause of complaint. In addition, I know from Joda-Time that users do not like these weird LMT offsets in the first place. They would much prefer something matching TimeZone. My proposal to base the LMT value on 1970-2010 is practical and sensible, but it is not the only choice. A fixed 1900 cutoff date for ZoneId could also be acceptable (matching TimeZone). Obviously some LMT will be exposed, but the problem would be no worse than today. I am concerned with choosing today's offset for the past however because that makes the application code very brittle. Arguing that we are followig the "standard" is not sensible when the standard's authors tell you not to use that feature! TimeZone already forks the TZDB, so we are not in new territory here. Keeping JSR-310 using full TZDB LMT is far too risky given the personal intentions of the TZDB maintainer wrt this data. Stephen On 22 October 2013 05:16, Xueming Shen wrote: > Hi Stephen, > > The current j.u.TimeZone implementation DOES use LMT. If the LMT is > defined/used cross > the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example the > offset for > Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the LMT 10.34.36. > Yes, if the > LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ. > > So if the LMT is removed from the JSR310 zdt, inevitably we are going to > have problem to > handle those date/time that fall into the period that uses LMT (after > 1900.11) when converting > between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can > remove the LMT > from the j.u.TimeZone for obvious compatibility reason. Sure, arguably > because the > j.u.Timezone 1900.1.1 cutoff, we are having this problem already for > date/time before the > 1900 cutoff, but the removal is just to make thing worse. > > As you suggested in the bug report, the problem is what to replace the LMT > with. Honestly > I don't think any proposed alternative is better than the LMT (basically > it's the tzdb's solution > for this unsolvable problem, what offset to use for that particular zone > before any timezone > even get defined for that area). And what you're proposing basically is to > fork the tzdb for > that part of date/time, replacing the location-based LMT with your own > algorithm, for > non-convincing reason. Yes, the LMT is not ideal, but "to calculate and use > a longest standard > used between 1970 and 2010" really does not make thing any better. While > it's true that it's > "simple and deterministic", but it's still not correct at all for that > period of time. The cost is to > fork the standard tzdb data and walk away from our "standard based" design > principal for > timezone data. I agree the choice of the "location" for some particular > zones might not be > ideal/correct/reasonable, but I don't think this is a big enough issue for > the cost of forking > from the tzdb data for Java date/time. > > I would suggest to simply keep the LMT asis, and close this RFE/bug, at > least for now. > > Thanks, > Sherman > > > From xueming.shen at oracle.com Tue Oct 22 11:49:40 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 22 Oct 2013 11:49:40 -0700 Subject: [threeten-dev] JDK-8024267 Stop using LMT for time-zones In-Reply-To: References: <5265FC3A.7050800@oracle.com> Message-ID: <5266C8C4.606@oracle.com> On 10/22/2013 08:12 AM, Stephen Colebourne wrote: > The Theory file in TZDB defines what LMT is and how it will be treated > https://github.com/eggert/tz/blob/master/Theory#L352 > > "In short, many, perhaps most, of the tz database's pre-1970 and > future time stamps are either wrong or misleading. Any attempt to > pass the tz database off as the definition of time should be > unacceptable to anybody who cares about the facts. In particular, the > tz database's LMT offsets should not be considered meaningful, and > should not prompt creation of zones merely because two locations > differ in LMT or transitioned to standard time at different dates." > It is the fact everybody here already knew:-) There is no such thing called timezone back then. As a matter of fact, it's theoretically impossible to have an accurate/correct or say meaningful zdt for date/time before any tz even defined. You have to reasonably "define" a zone offset for those date/time, if a zdt is really desired. Personally I believe the location based solution is a reasonable approach, but I would just pick the "standard" offset of that particular location, without seconds and even minutes, but I don't think anyone will follow and build their application on my believe:-) LMT is tzdb's approach to define the offset for this issue. Yes, as its theory claims, it's not really the factual timezone offset back then and you should not bet your future on that. But, it's still a database the industry follows and lots of platforms build their libraries on, especially it is now officially maintained by a standard body. So I don't see a compelling reason that java.time should just derives from it. Given the great flexibility of JSR310 tz data provider framework:-) anyone actually can implement and replace the default tzdb with whatever they believe to be more practical and sensible, if desired. So maybe it's a reasonable decision to just leave the tzdb/LMT as is, for the default implementation. That said, this issue probably deserves more discussions. How about change this one to RFE (it is really not a bug at first place) and remove it from the jdk8 target list and continue the discussion for a better alternative for the future release, even the jdk8u, if we can reach a consensus? -Sherman > What this means in practice is that LMT values have been and will be > changed on a whim, with absolutely no rationale for the change. > > In practical terms, this means that a user of JSR-310 who creates a > ZonedDateTime representing a date in 1800 will see an LMT offset > measured in seconds, such as +01:32:29. When the TZDB is updated, this > offset may change, and there will be no valid rationale for the > change. That randomness of change will be a major cause of complaint. > > In addition, I know from Joda-Time that users do not like these weird > LMT offsets in the first place. They would much prefer something > matching TimeZone. > > My proposal to base the LMT value on 1970-2010 is practical and > sensible, but it is not the only choice. > > A fixed 1900 cutoff date for ZoneId could also be acceptable (matching > TimeZone). Obviously some LMT will be exposed, but the problem would > be no worse than today. I am concerned with choosing today's offset > for the past however because that makes the application code very > brittle. > > Arguing that we are followig the "standard" is not sensible when the > standard's authors tell you not to use that feature! > > TimeZone already forks the TZDB, so we are not in new territory here. > > Keeping JSR-310 using full TZDB LMT is far too risky given the > personal intentions of the TZDB maintainer wrt this data. > Stephen > > > > > On 22 October 2013 05:16, Xueming Shen wrote: >> Hi Stephen, >> >> The current j.u.TimeZone implementation DOES use LMT. If the LMT is >> defined/used cross >> the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example the >> offset for >> Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the LMT 10.34.36. >> Yes, if the >> LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ. >> >> So if the LMT is removed from the JSR310 zdt, inevitably we are going to >> have problem to >> handle those date/time that fall into the period that uses LMT (after >> 1900.11) when converting >> between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can >> remove the LMT >> from the j.u.TimeZone for obvious compatibility reason. Sure, arguably >> because the >> j.u.Timezone 1900.1.1 cutoff, we are having this problem already for >> date/time before the >> 1900 cutoff, but the removal is just to make thing worse. >> >> As you suggested in the bug report, the problem is what to replace the LMT >> with. Honestly >> I don't think any proposed alternative is better than the LMT (basically >> it's the tzdb's solution >> for this unsolvable problem, what offset to use for that particular zone >> before any timezone >> even get defined for that area). And what you're proposing basically is to >> fork the tzdb for >> that part of date/time, replacing the location-based LMT with your own >> algorithm, for >> non-convincing reason. Yes, the LMT is not ideal, but "to calculate and use >> a longest standard >> used between 1970 and 2010" really does not make thing any better. While >> it's true that it's >> "simple and deterministic", but it's still not correct at all for that >> period of time. The cost is to >> fork the standard tzdb data and walk away from our "standard based" design >> principal for >> timezone data. I agree the choice of the "location" for some particular >> zones might not be >> ideal/correct/reasonable, but I don't think this is a big enough issue for >> the cost of forking >> from the tzdb data for Java date/time. >> >> I would suggest to simply keep the LMT asis, and close this RFE/bug, at >> least for now. >> >> Thanks, >> Sherman >> >> >> From scolebourne at joda.org Wed Oct 23 15:59:15 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 23 Oct 2013 23:59:15 +0100 Subject: [threeten-dev] JDK-8024267 Stop using LMT for time-zones In-Reply-To: <5266C8C4.606@oracle.com> References: <5265FC3A.7050800@oracle.com> <5266C8C4.606@oracle.com> Message-ID: My concern is now more focussed on TimeZone and ZoneId being different. This has caused users issues when using Joda-Time. Simply adopting the TimeZone scheme for ZoneId now will reduce pain for end users. If we make ZoneId match TimeZone then I'd be happy to move enhancing the shared definition to an RFE (assuming a willingness to change the definition of both TimeZone and ZoneId in the future) The original "bug" status is because the TZDB mailing list indicated clearly IMO that widespread use of LMT was a bug. Feel free to ask the TZDB list for clarification. Stephen On 22 October 2013 19:49, Xueming Shen wrote: > On 10/22/2013 08:12 AM, Stephen Colebourne wrote: >> >> The Theory file in TZDB defines what LMT is and how it will be treated >> https://github.com/eggert/tz/blob/master/Theory#L352 >> >> "In short, many, perhaps most, of the tz database's pre-1970 and >> future time stamps are either wrong or misleading. Any attempt to >> pass the tz database off as the definition of time should be >> unacceptable to anybody who cares about the facts. In particular, the >> tz database's LMT offsets should not be considered meaningful, and >> should not prompt creation of zones merely because two locations >> differ in LMT or transitioned to standard time at different dates." >> > > It is the fact everybody here already knew:-) There is no such thing called > timezone > back then. As a matter of fact, it's theoretically impossible to have an > accurate/correct > or say meaningful zdt for date/time before any tz even defined. You have to > reasonably > "define" a zone offset for those date/time, if a zdt is really desired. > Personally I believe > the location based solution is a reasonable approach, but I would just pick > the "standard" > offset of that particular location, without seconds and even minutes, but I > don't think > anyone will follow and build their application on my believe:-) LMT is > tzdb's approach > to define the offset for this issue. Yes, as its theory claims, it's not > really the factual > timezone offset back then and you should not bet your future on that. But, > it's still a > database the industry follows and lots of platforms build their libraries > on, especially > it is now officially maintained by a standard body. So I don't see a > compelling reason > that java.time should just derives from it. Given the great flexibility of > JSR310 tz data > provider framework:-) anyone actually can implement and replace the default > tzdb > with whatever they believe to be more practical and sensible, if desired. So > maybe > it's a reasonable decision to just leave the tzdb/LMT as is, for the default > implementation. > > That said, this issue probably deserves more discussions. How about change > this > one to RFE (it is really not a bug at first place) and remove it from the > jdk8 target > list and continue the discussion for a better alternative for the future > release, even > the jdk8u, if we can reach a consensus? > > -Sherman > > >> What this means in practice is that LMT values have been and will be >> changed on a whim, with absolutely no rationale for the change. >> >> In practical terms, this means that a user of JSR-310 who creates a >> ZonedDateTime representing a date in 1800 will see an LMT offset >> measured in seconds, such as +01:32:29. When the TZDB is updated, this >> offset may change, and there will be no valid rationale for the >> change. That randomness of change will be a major cause of complaint. >> >> In addition, I know from Joda-Time that users do not like these weird >> LMT offsets in the first place. They would much prefer something >> matching TimeZone. >> >> My proposal to base the LMT value on 1970-2010 is practical and >> sensible, but it is not the only choice. >> >> A fixed 1900 cutoff date for ZoneId could also be acceptable (matching >> TimeZone). Obviously some LMT will be exposed, but the problem would >> be no worse than today. I am concerned with choosing today's offset >> for the past however because that makes the application code very >> brittle. >> >> Arguing that we are followig the "standard" is not sensible when the >> standard's authors tell you not to use that feature! >> >> TimeZone already forks the TZDB, so we are not in new territory here. >> >> Keeping JSR-310 using full TZDB LMT is far too risky given the >> personal intentions of the TZDB maintainer wrt this data. >> Stephen >> >> >> >> >> On 22 October 2013 05:16, Xueming Shen wrote: >>> >>> Hi Stephen, >>> >>> The current j.u.TimeZone implementation DOES use LMT. If the LMT is >>> defined/used cross >>> the 1900.1.1 j.u.TimeZone cutoff date (by the tzdb data). For example the >>> offset for >>> Asia/Kamchatka from 1900.1.1 to the 1922.11.10 will be the LMT 10.34.36. >>> Yes, if the >>> LMT end date is before 1900.1.1, the LMT will not be used by the j.u.TZ. >>> >>> So if the LMT is removed from the JSR310 zdt, inevitably we are going to >>> have problem to >>> handle those date/time that fall into the period that uses LMT (after >>> 1900.11) when converting >>> between JSR310 zdt and j.u.TZ+Calendar date/time. I don't think we can >>> remove the LMT >>> from the j.u.TimeZone for obvious compatibility reason. Sure, arguably >>> because the >>> j.u.Timezone 1900.1.1 cutoff, we are having this problem already for >>> date/time before the >>> 1900 cutoff, but the removal is just to make thing worse. >>> >>> As you suggested in the bug report, the problem is what to replace the >>> LMT >>> with. Honestly >>> I don't think any proposed alternative is better than the LMT (basically >>> it's the tzdb's solution >>> for this unsolvable problem, what offset to use for that particular zone >>> before any timezone >>> even get defined for that area). And what you're proposing basically is >>> to >>> fork the tzdb for >>> that part of date/time, replacing the location-based LMT with your own >>> algorithm, for >>> non-convincing reason. Yes, the LMT is not ideal, but "to calculate and >>> use >>> a longest standard >>> used between 1970 and 2010" really does not make thing any better. While >>> it's true that it's >>> "simple and deterministic", but it's still not correct at all for that >>> period of time. The cost is to >>> fork the standard tzdb data and walk away from our "standard based" >>> design >>> principal for >>> timezone data. I agree the choice of the "location" for some particular >>> zones might not be >>> ideal/correct/reasonable, but I don't think this is a big enough issue >>> for >>> the cost of forking >>> from the tzdb data for Java date/time. >>> >>> I would suggest to simply keep the LMT asis, and close this RFE/bug, at >>> least for now. >>> >>> Thanks, >>> Sherman >>> >>> >>> >