From scolebourne at joda.org Sun Jun 2 14:49:57 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Sun, 02 Jun 2013 21:49:57 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 5 new changesets Message-ID: <20130602215133.1195B48EC7@hg.openjdk.java.net> Changeset: cf33e461f819 Author: scolebourne Date: 2013-05-30 21:35 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cf33e461f819 Lenient parsing of WeekFields Fixes #317 ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java Changeset: 9b12f3b38e14 Author: scolebourne Date: 2013-05-31 00:15 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/9b12f3b38e14 Tidy imports and Javadoc ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalAccessor.java Changeset: bf5678a8051f Author: scolebourne Date: 2013-05-31 00:29 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bf5678a8051f Lenient resolve for non-ISO calendars See #318 ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java Changeset: 73fac9acbaa1 Author: scolebourne Date: 2013-06-02 22:38 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/73fac9acbaa1 Fix Javadoc See #317 feedback ! src/share/classes/java/time/temporal/WeekFields.java Changeset: 7101b3a2e708 Author: scolebourne Date: 2013-06-02 22:44 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7101b3a2e708 Merge ! test/java/time/tck/java/time/temporal/TCKWeekFields.java From roger.riggs at oracle.com Tue Jun 4 10:52:34 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 04 Jun 2013 17:52:34 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130604175321.E0CF148F3D@hg.openjdk.java.net> Changeset: 8d2a4d67e7fd Author: rriggs Date: 2013-06-04 13:40 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/8d2a4d67e7fd Bugid:8015113: Issue #314 ChronoField.getName method redundant with ChronoField.name method - Changed uses of TemporalUnit and TemporaField.getName to use toString - Defined TemporalField.toString and TemporalUnit.toString to have getName semantics/forms - Removed Temporal/ChronoField.getName and Temporal/ChronoUnit.getName - Updated tests ! src/share/classes/java/time/DayOfWeek.java ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/Month.java ! src/share/classes/java/time/MonthDay.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZoneOffset.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/Era.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! src/share/classes/java/time/format/Parsed.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/JulianFields.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/TemporalField.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! src/share/classes/java/time/temporal/ValueRange.java ! src/share/classes/java/time/temporal/WeekFields.java ! test/java/time/tck/java/time/MockSimplePeriod.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java ! test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java ! test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java ! test/java/time/test/java/time/MockSimplePeriod.java ! test/java/time/test/java/time/format/TestNumberPrinter.java ! test/java/time/test/java/time/format/TestReducedPrinter.java ! test/java/time/test/java/time/temporal/MockFieldNoValue.java ! test/java/time/test/java/time/temporal/MockFieldValue.java Changeset: c23d7d5e8d42 Author: rriggs Date: 2013-06-04 13:52 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c23d7d5e8d42 Merge ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/temporal/ChronoField.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/TemporalAccessor.java ! src/share/classes/java/time/temporal/WeekFields.java + test/java/time/tck/java/time/format/TCKFormatStyle.java + test/java/time/tck/java/time/format/TCKResolverStyle.java + test/java/time/tck/java/time/format/TCKSignStyle.java + test/java/time/tck/java/time/temporal/TCKChronoField.java + test/java/time/tck/java/time/temporal/TCKChronoUnit.java ! test/java/time/tck/java/time/temporal/TCKWeekFields.java ! test/java/time/tck/java/time/zone/TCKZoneRules.java From janarioliver at gmail.com Tue Jun 4 17:34:34 2013 From: janarioliver at gmail.com (Janario Oliveira) Date: Tue, 4 Jun 2013 21:34:34 -0300 Subject: [threeten-dev] Month methods Message-ID: Hi guys! I was looking the api and an interesting thing called my attention The Month(enum) doesn't have the same methods found in others classes like LocalDate, LocalDateTime and almost every mainly classes I've seen The methods are now() and format(DateTimeFormatter formatter) Without these I should do something like: Month currentMonth = LocalDate.now().getMonth(); //It's ok but different from the way I prefer(LocalDate.format(DateTimeFormatter formatter)) private static final DateTimeFormatter MY_MONTH_FORMATTER=DateTimeFormatter.ofPattern("MMM"); MY_MONTH_FORMATTER.format(currentMonth) Is it possible to provide these methods? They would be much more useful once other classes have this standard Thanks Janario Oliveira From scolebourne at joda.org Wed Jun 5 03:13:24 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Jun 2013 11:13:24 +0100 Subject: [threeten-dev] Month methods In-Reply-To: References: Message-ID: Adding the now() methods would need 3 extra methods on each of Month and DayOfWeek. 6 extra methods. The format() method is alreday handled by getDisplayName(). Stephen On 5 June 2013 01:34, Janario Oliveira wrote: > Hi guys! > > I was looking the api and an interesting thing called my attention > > The Month(enum) doesn't have the same methods found in others classes like > LocalDate, LocalDateTime and almost every mainly classes I've seen > > The methods are now() and format(DateTimeFormatter formatter) > > Without these I should do something like: > Month currentMonth = LocalDate.now().getMonth(); > > //It's ok but different from the way I > prefer(LocalDate.format(DateTimeFormatter formatter)) > private static final DateTimeFormatter > MY_MONTH_FORMATTER=DateTimeFormatter.ofPattern("MMM"); > MY_MONTH_FORMATTER.format(currentMonth) > > Is it possible to provide these methods? > They would be much more useful once other classes have this standard > > Thanks > Janario Oliveira From roger.riggs at oracle.com Wed Jun 5 10:23:42 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 05 Jun 2013 13:23:42 -0400 Subject: [threeten-dev] Review rename of periodUntil() to until() Message-ID: <51AF741E.9020105@oracle.com> Issue #311 recommends renaming the periodUntil method to until() in the Temporal and ChronoLocalDate interfaces. It affects the implementations of these interfaces and tests. Please review and comment on the change: http://cr.openjdk.java.net/~rriggs/webrev-until-311/ Thanks, Roger From scolebourne at joda.org Wed Jun 5 13:11:14 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 5 Jun 2013 21:11:14 +0100 Subject: [threeten-dev] Review rename of periodUntil() to until() In-Reply-To: <51AF741E.9020105@oracle.com> References: <51AF741E.9020105@oracle.com> Message-ID: Looks good to me. Definitely looks like an improvement. thanks Stephen On 5 June 2013 18:23, roger riggs wrote: > Issue #311 recommends > renaming the periodUntil method to until() > in the Temporal and ChronoLocalDate interfaces. > It affects the implementations of these interfaces and tests. > > Please review and comment on the change: > http://cr.openjdk.java.net/~rriggs/webrev-until-311/ > > Thanks, Roger > From roger.riggs at oracle.com Wed Jun 5 13:19:56 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 05 Jun 2013 20:19:56 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Bugid:8016002: Issue #311 Rename periodUntil() to until() Message-ID: <20130605202044.89FD548FC5@hg.openjdk.java.net> Changeset: b80297d05eb9 Author: rriggs Date: 2013-06-05 16:19 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/b80297d05eb9 Bugid:8016002: Issue #311 Rename periodUntil() to until() - Renamed Temporal.periodUntil to until and ChronoLocalDate.periodUntil to until. - Updated tests ! src/share/classes/java/time/Duration.java ! src/share/classes/java/time/Instant.java ! src/share/classes/java/time/LocalDate.java ! src/share/classes/java/time/LocalDateTime.java ! src/share/classes/java/time/LocalTime.java ! src/share/classes/java/time/OffsetDateTime.java ! src/share/classes/java/time/OffsetTime.java ! src/share/classes/java/time/Period.java ! src/share/classes/java/time/Year.java ! src/share/classes/java/time/YearMonth.java ! src/share/classes/java/time/ZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java ! src/share/classes/java/time/temporal/ChronoUnit.java ! src/share/classes/java/time/temporal/IsoFields.java ! src/share/classes/java/time/temporal/Temporal.java ! src/share/classes/java/time/temporal/TemporalUnit.java ! test/java/time/tck/java/time/TCKInstant.java ! test/java/time/tck/java/time/TCKLocalDate.java ! test/java/time/tck/java/time/TCKLocalDateTime.java ! test/java/time/tck/java/time/TCKLocalTime.java ! test/java/time/tck/java/time/TCKOffsetTime.java ! test/java/time/tck/java/time/TCKYear.java ! test/java/time/tck/java/time/TCKYearMonth.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/chrono/CopticDate.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java From roger.riggs at oracle.com Sat Jun 8 10:34:25 2013 From: roger.riggs at oracle.com (roger riggs) Date: Sat, 08 Jun 2013 13:34:25 -0400 Subject: [threeten-dev] ZoneIdPrinterParser #262 Message-ID: <51B36B21.7010802@oracle.com> Hi, Inissue #262 , the behavior of the DateTimeFormatterBuilder for ZoneIds should be aligned with ZoneId.of as to which zoneid are accepted and whether they create ZoneOffsets or ZoneIds. Please review the changes and comment whether the test cases are correct. There are a number of input values that were previously valid for parsing of ZoneIds that are no longer valid (to match ZoneId). For example, "UTC0" is no longer valid. One inconvenience in the code after a prefix and the offset value is parsed there is no public method to create the ZoneId. The ZoneId.of method as to re-parse the input. The method static ZoneRegion ofPrefixedOffset(String zoneId, ZoneOffset offset) is use for this purpose but it is package private and can't be used from the format package. Is it reasonable to add a method to ZoneId for a similar purpose? http://cr.openjdk.java.net/~rriggs/webrev-zoneid-parser-262/ Thanks, Roger From scolebourne at joda.org Mon Jun 10 08:35:06 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 10 Jun 2013 16:35:06 +0100 Subject: [threeten-dev] ZoneIdPrinterParser #262 In-Reply-To: <51B36B21.7010802@oracle.com> References: <51B36B21.7010802@oracle.com> Message-ID: On 8 June 2013 18:34, roger riggs wrote: > Please review the changes and comment whether the test cases are correct. > There are a number of input values that were previously valid for parsing > of ZoneIds that are no longer valid (to match ZoneId). For example, "UTC0" > is no longer valid. Looks right to me. It may be worth a cross-test with ZoneId.of to ensure both work the same. > One inconvenience in the code after a prefix and the offset value is parsed > there is no public method to create the ZoneId. The ZoneId.of method as to > re-parse the input. > The method static ZoneRegion ofPrefixedOffset(String zoneId, ZoneOffset > offset) > is use for this purpose but it is package private and can't be used from the > format package. > Is it reasonable to add a method to ZoneId for a similar purpose? I think adding a ZoneId.ofOffset(String prefix, ZoneOffset offset) method would be OK. I don't think it needs a longer name than "ofOffset" because the arguments and javadoc should be clear enough. I think that as well as "UTC, "UT" and "GMT" prefixes, it should accept a blank string, which just returns the offset. thanks Stephen > http://cr.openjdk.java.net/~rriggs/webrev-zoneid-parser-262/ > > Thanks, Roger > > > From roger.riggs at oracle.com Mon Jun 10 14:08:43 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 10 Jun 2013 17:08:43 -0400 Subject: [threeten-dev] ZoneIdPrinterParser #262 In-Reply-To: References: <51B36B21.7010802@oracle.com> Message-ID: <51B6405B.8040108@oracle.com> Hi, Updated the webrev to use a new ZoneId.ofOffset(prefix, zoneOffset) method. Corrected some tests that still allowed UT0, UTC0, GMT0 and the prior forms of ZoneIds. This change also affects the default parser of ZoneDateTime. The results do match ZoneId.of. http://cr.openjdk.java.net/~rriggs/webrev-zoneid-parser-262/ Please review and comment. Thanks, Roger On 6/10/2013 11:35 AM, Stephen Colebourne wrote: > On 8 June 2013 18:34, roger riggs wrote: >> Please review the changes and comment whether the test cases are correct. >> There are a number of input values that were previously valid for parsing >> of ZoneIds that are no longer valid (to match ZoneId). For example, "UTC0" >> is no longer valid. > Looks right to me. It may be worth a cross-test with ZoneId.of to > ensure both work the same. > >> One inconvenience in the code after a prefix and the offset value is parsed >> there is no public method to create the ZoneId. The ZoneId.of method as to >> re-parse the input. >> The method static ZoneRegion ofPrefixedOffset(String zoneId, ZoneOffset >> offset) >> is use for this purpose but it is package private and can't be used from the >> format package. >> Is it reasonable to add a method to ZoneId for a similar purpose? > I think adding a ZoneId.ofOffset(String prefix, ZoneOffset offset) > method would be OK. I don't think it needs a longer name than > "ofOffset" because the arguments and javadoc should be clear enough. I > think that as well as "UTC, "UT" and "GMT" prefixes, it should accept > a blank string, which just returns the offset. > > thanks > Stephen > > >> http://cr.openjdk.java.net/~rriggs/webrev-zoneid-parser-262/ >> >> Thanks, Roger >> >> >> From scolebourne at joda.org Mon Jun 10 15:42:22 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 10 Jun 2013 23:42:22 +0100 Subject: [threeten-dev] ZoneIdPrinterParser #262 In-Reply-To: <51B6405B.8040108@oracle.com> References: <51B36B21.7010802@oracle.com> <51B6405B.8040108@oracle.com> Message-ID: ZoneId has a meaningless if statement now line 473. You fixed the third Javadoc example in DTFBuilder, but not the first two, line 964 and 1014 TCKZoneId has a mispelling - "nullPrefixOfOffste" It should also have a test for a valid prefix but a null offset. Otherwise looks good. thanks Stephen On 10 June 2013 22:08, roger riggs wrote: > Hi, > > Updated the webrev to use a new ZoneId.ofOffset(prefix, zoneOffset) method. > Corrected some tests that still allowed UT0, UTC0, GMT0 and the prior forms > of ZoneIds. This change also affects the default parser of ZoneDateTime. > The results do match ZoneId.of. > > http://cr.openjdk.java.net/~rriggs/webrev-zoneid-parser-262/ > > Please review and comment. > > Thanks, Roger > > > > > On 6/10/2013 11:35 AM, Stephen Colebourne wrote: >> >> On 8 June 2013 18:34, roger riggs wrote: >>> >>> Please review the changes and comment whether the test cases are correct. >>> There are a number of input values that were previously valid for parsing >>> of ZoneIds that are no longer valid (to match ZoneId). For example, >>> "UTC0" >>> is no longer valid. >> >> Looks right to me. It may be worth a cross-test with ZoneId.of to >> ensure both work the same. >> >>> One inconvenience in the code after a prefix and the offset value is >>> parsed >>> there is no public method to create the ZoneId. The ZoneId.of method as >>> to >>> re-parse the input. >>> The method static ZoneRegion ofPrefixedOffset(String zoneId, ZoneOffset >>> offset) >>> is use for this purpose but it is package private and can't be used from >>> the >>> format package. >>> Is it reasonable to add a method to ZoneId for a similar purpose? >> >> I think adding a ZoneId.ofOffset(String prefix, ZoneOffset offset) >> method would be OK. I don't think it needs a longer name than >> "ofOffset" because the arguments and javadoc should be clear enough. I >> think that as well as "UTC, "UT" and "GMT" prefixes, it should accept >> a blank string, which just returns the offset. >> >> thanks >> Stephen >> >> >>> http://cr.openjdk.java.net/~rriggs/webrev-zoneid-parser-262/ >>> >>> Thanks, Roger >>> >>> >>> > From roger.riggs at oracle.com Tue Jun 11 06:26:32 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Tue, 11 Jun 2013 13:26:32 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Bugid: Issue #262 Normalizing UTC time-zone to offset Z causes problems Message-ID: <20130611132736.4882748133@hg.openjdk.java.net> Changeset: 5a1d4618329c Author: rriggs Date: 2013-06-11 09:25 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/5a1d4618329c Bugid: Issue #262 Normalizing UTC time-zone to offset Z causes problems - Revised ZoneIdPrinterParser to match the parsing behavior of ZoneId.of. - Added ZoneId.ofOffset(prefix, offset) - Updated tests ! src/share/classes/java/time/ZoneId.java ! src/share/classes/java/time/ZoneRegion.java ! src/share/classes/java/time/format/DateTimeFormatterBuilder.java ! test/java/time/tck/java/time/TCKZoneId.java ! test/java/time/tck/java/time/TCKZonedDateTime.java ! test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java From roger.riggs at oracle.com Tue Jun 11 07:03:14 2013 From: roger.riggs at oracle.com (roger riggs) Date: Tue, 11 Jun 2013 10:03:14 -0400 Subject: [threeten-dev] HijrahDate.with(DAY_OF_YEAR) bug Message-ID: <51B72E22.3010803@oracle.com> Hi, There is a bug [8016215] in the implementation of HijrahDate.with(DAY_OF_YEAR, n) and also HijrahDate.get(DAY_OF_YEAR). Please review the corrected code and tests. http://cr.openjdk.java.net/~rriggs/webrev-hijrah-day-of-year-8016215/ Thanks, Roger [8016215] http://bugs.sun.com/view_bug.do?bug_id=8016215 From scolebourne at joda.org Tue Jun 11 14:50:38 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 11 Jun 2013 22:50:38 +0100 Subject: [threeten-dev] HijrahDate.with(DAY_OF_YEAR) bug In-Reply-To: <51B72E22.3010803@oracle.com> References: <51B72E22.3010803@oracle.com> Message-ID: Looks fine AFAICT. Stephen On 11 June 2013 15:03, roger riggs wrote: > Hi, > > There is a bug [8016215] in the implementation of > HijrahDate.with(DAY_OF_YEAR, n) > and also HijrahDate.get(DAY_OF_YEAR). > > Please review the corrected code and tests. > > http://cr.openjdk.java.net/~rriggs/webrev-hijrah-day-of-year-8016215/ > > Thanks, Roger > > [8016215] http://bugs.sun.com/view_bug.do?bug_id=8016215 > From roger.riggs at oracle.com Wed Jun 12 07:23:27 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Wed, 12 Jun 2013 14:23:27 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Bugid: 8016215 HijrahDate.with(DAY_OF_YEAR) sets wrong date Message-ID: <20130612142413.B7F0A4818E@hg.openjdk.java.net> Changeset: ab19cc860f04 Author: rriggs Date: 2013-06-12 10:23 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ab19cc860f04 Bugid: 8016215 HijrahDate.with(DAY_OF_YEAR) sets wrong date - Corrected implementation of HijrahDate.with(DAY_OF_YEAR, n) - Corrected implementation of HijrahDate.get(DAY_OF_YEAR) - Updated tests ! src/share/classes/java/time/chrono/HijrahDate.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java From chand.basha at oracle.com Tue Jun 18 13:45:01 2013 From: chand.basha at oracle.com (Chand Basha) Date: Tue, 18 Jun 2013 15:45:01 -0500 Subject: [threeten-dev] Hijrah Tests Review Request Message-ID: <51C0C6CD.4010903@oracle.com> Hi, I have added few new tests to TestUmmAlQuraChronology.java and removed/cleaned up existing TCKHijrahChronology.java files. Roger graciously created a review for me http://cr.openjdk.java.net/~rriggs/webrev-hijrah-calendar-tests-8016898. Thanks a lot Roger. I would appreciate if you could review it and let me know if there are any questions/concerns to commit the files. Thanks, - Basha From scolebourne at joda.org Wed Jun 19 02:15:26 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Jun 2013 10:15:26 +0100 Subject: [threeten-dev] Hijrah Tests Review Request In-Reply-To: <51C0C6CD.4010903@oracle.com> References: <51C0C6CD.4010903@oracle.com> Message-ID: The TCK test involves a lot of deletion. Was that deliberate? The TestUmmAlQuraChronology class (non TCK) has date creation indirectly via lines this this: {1318, 01, 01, 1900, 04, 30}, but the "01" and "04" are octal numbers, not "normal" constants. Octal numbers may look pretty for dates, but they don't work for "08" and "09" and thus confuse users browsing this code (looking for example API usage). The comment sections (grouping similar tests) are incomplete. For example. you could do with a dashed line or comment header at line 655 as the tests below there don't refer to the previous comment section header at line 623. Alternately, remove all the comment sections. The tests themselves look pretty comprehensive, although I haven't checked the actual dates or logic are correct. Stephen On 18 June 2013 21:45, Chand Basha wrote: > Hi, > > I have added few new tests to TestUmmAlQuraChronology.java and > removed/cleaned up existing TCKHijrahChronology.java files. Roger graciously > created a review for me > http://cr.openjdk.java.net/~rriggs/webrev-hijrah-calendar-tests-8016898. > Thanks a lot Roger. > > I would appreciate if you could review it and let me know if there are any > questions/concerns to commit the files. > > Thanks, > - Basha From roger.riggs at oracle.com Wed Jun 19 07:48:15 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 19 Jun 2013 10:48:15 -0400 Subject: [threeten-dev] Hijrah Tests Review Request In-Reply-To: References: <51C0C6CD.4010903@oracle.com> Message-ID: <51C1C4AF.6050603@oracle.com> On 6/19/2013 5:15 AM, Stephen Colebourne wrote: > The TCK test involves a lot of deletion. Was that deliberate? Since they had calendar data dependencies, they are not valid as TCK tests. I asked that they be moved to the UmmAlQura tests. Roger > > The TestUmmAlQuraChronology class (non TCK) has date creation > indirectly via lines this this: > {1318, 01, 01, 1900, 04, 30}, > but the "01" and "04" are octal numbers, not "normal" constants. Octal > numbers may look pretty for dates, but they don't work for "08" and > "09" and thus confuse users browsing this code (looking for example > API usage). > > The comment sections (grouping similar tests) are incomplete. For > example. you could do with a dashed line or comment header at line 655 > as the tests below there don't refer to the previous comment section > header at line 623. Alternately, remove all the comment sections. > > The tests themselves look pretty comprehensive, although I haven't > checked the actual dates or logic are correct. > > Stephen > > > On 18 June 2013 21:45, Chand Basha wrote: >> Hi, >> >> I have added few new tests to TestUmmAlQuraChronology.java and >> removed/cleaned up existing TCKHijrahChronology.java files. Roger graciously >> created a review for me >> http://cr.openjdk.java.net/~rriggs/webrev-hijrah-calendar-tests-8016898. >> Thanks a lot Roger. >> >> I would appreciate if you could review it and let me know if there are any >> questions/concerns to commit the files. >> >> Thanks, >> - Basha From chand.basha at oracle.com Wed Jun 19 09:32:35 2013 From: chand.basha at oracle.com (chand basha) Date: Wed, 19 Jun 2013 11:32:35 -0500 Subject: [threeten-dev] Hijrah Tests Review Request In-Reply-To: <51C1C4AF.6050603@oracle.com> References: <51C0C6CD.4010903@oracle.com> <51C1C4AF.6050603@oracle.com> Message-ID: <51C1DD23.8020305@oracle.com> Hi Stephen, Thanks for your quick feedback. Please see my comments inline. Thanks, - Basha On 6/19/2013 9:48 AM, roger riggs wrote: > > On 6/19/2013 5:15 AM, Stephen Colebourne wrote: >> The TCK test involves a lot of deletion. Was that deliberate? > Since they had calendar data dependencies, they are not valid as TCK > tests. > I asked that they be moved to the UmmAlQura tests. > > Roger > >> >> The TestUmmAlQuraChronology class (non TCK) has date creation >> indirectly via lines this this: >> {1318, 01, 01, 1900, 04, 30}, >> but the "01" and "04" are octal numbers, not "normal" constants. Octal >> numbers may look pretty for dates, but they don't work for "08" and >> "09" and thus confuse users browsing this code (looking for example >> API usage). >> >> Is it okay if the numbers are changed from "04" to "4" and so on? If >> not, I can change the code to have direct date creation. >> >> The comment sections (grouping similar tests) are incomplete. For >> example. you could do with a dashed line or comment header at line 655 >> as the tests below there don't refer to the previous comment section >> header at line 623. Alternately, remove all the comment sections. >> >> Agreed. Even though the names of the data provider and the test >> itself are obvious, having a simple comment would help in >> understanding the tests. So I will add comments appropriately. >> >> The tests themselves look pretty comprehensive, although I haven't >> checked the actual dates or logic are correct. >> >> Stephen >> >> >> On 18 June 2013 21:45, Chand Basha wrote: >>> Hi, >>> >>> I have added few new tests to TestUmmAlQuraChronology.java and >>> removed/cleaned up existing TCKHijrahChronology.java files. Roger >>> graciously >>> created a review for me >>> http://cr.openjdk.java.net/~rriggs/webrev-hijrah-calendar-tests-8016898. >>> >>> Thanks a lot Roger. >>> >>> I would appreciate if you could review it and let me know if there >>> are any >>> questions/concerns to commit the files. >>> >>> Thanks, >>> - Basha > From scolebourne at joda.org Wed Jun 19 14:34:41 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 19 Jun 2013 22:34:41 +0100 Subject: [threeten-dev] Hijrah Tests Review Request In-Reply-To: <51C1DD23.8020305@oracle.com> References: <51C0C6CD.4010903@oracle.com> <51C1C4AF.6050603@oracle.com> <51C1DD23.8020305@oracle.com> Message-ID: On 19 June 2013 17:32, chand basha wrote: >>> The TestUmmAlQuraChronology class (non TCK) has date creation >>> indirectly via lines this this: >>> {1318, 01, 01, 1900, 04, 30}, >>> but the "01" and "04" are octal numbers, not "normal" constants. Octal >>> numbers may look pretty for dates, but they don't work for "08" and >>> "09" and thus confuse users browsing this code (looking for example >>> API usage). >>> >>> Is it okay if the numbers are changed from "04" to "4" and so on? If not, >>> I can change the code to have direct date creation. Yes, thats what needs to happen. Just change "04" to "4". Stephen From roger.riggs at oracle.com Fri Jun 21 14:17:41 2013 From: roger.riggs at oracle.com (roger riggs) Date: Fri, 21 Jun 2013 17:17:41 -0400 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR Message-ID: <51C4C2F5.9040609@oracle.com> A number of problems were found with the DAY_OF_YEAR field in JapaneseChronology/Date. The values for the lengthOfYear() and range were incorrectly computed interfering with the operation of get() and with(). The bugs.sun.com issue is: 8017105 Please review and comment: http://cr.openjdk.java.net/~rriggs/webrev-japanese-day-of-year-8017105/ Thanks, Roger From scolebourne at joda.org Mon Jun 24 03:26:02 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 24 Jun 2013 11:26:02 +0100 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: <51C4C2F5.9040609@oracle.com> References: <51C4C2F5.9040609@oracle.com> Message-ID: The patch is fine, except for a cut and paste "Hijrah". There are lots of issues to work out with Japanese. I'd like to get the two patches I put out integrated as well. https://github.com/ThreeTen/threeten/issues/299#issuecomment-19831206 https://github.com/ThreeTen/threeten/issues/318#issuecomment-19896959 The public factory methods are also weird too. ofYearDay(int,int) is public, unlike other date classes. Stephen On 21 June 2013 22:17, roger riggs wrote: > A number of problems were found with the DAY_OF_YEAR field in > JapaneseChronology/Date. > The values for the lengthOfYear() and range were incorrectly computed > interfering > with the operation of get() and with(). > > The bugs.sun.com issue is: 8017105 > > > Please review and comment: > > http://cr.openjdk.java.net/~rriggs/webrev-japanese-day-of-year-8017105/ > > Thanks, Roger > > From scolebourne at joda.org Mon Jun 24 04:21:16 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 24 Jun 2013 12:21:16 +0100 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: References: <51C4C2F5.9040609@oracle.com> Message-ID: And there is a disagreemnet as to the start of the Meiji era. sun.util.calendar.Era says 1868-01-01, wheras our Japanese Era says 1868-09-08. Is the old Sun class wrong here? Showa is also different by a day. The class needs a lot of tidying up I fear. Here are some more tests, with bugs commented out. https://gist.github.com/jodastephen/5849354 Who is working to fix this class? thanks Stephen On 24 June 2013 11:26, Stephen Colebourne wrote: > The patch is fine, except for a cut and paste "Hijrah". > > There are lots of issues to work out with Japanese. I'd like to get > the two patches I put out integrated as well. > https://github.com/ThreeTen/threeten/issues/299#issuecomment-19831206 > https://github.com/ThreeTen/threeten/issues/318#issuecomment-19896959 > > The public factory methods are also weird too. ofYearDay(int,int) is > public, unlike other date classes. > Stephen > > > > On 21 June 2013 22:17, roger riggs wrote: >> A number of problems were found with the DAY_OF_YEAR field in >> JapaneseChronology/Date. >> The values for the lengthOfYear() and range were incorrectly computed >> interfering >> with the operation of get() and with(). >> >> The bugs.sun.com issue is: 8017105 >> >> >> Please review and comment: >> >> http://cr.openjdk.java.net/~rriggs/webrev-japanese-day-of-year-8017105/ >> >> Thanks, Roger >> >> From scolebourne at joda.org Mon Jun 24 06:13:43 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Mon, 24 Jun 2013 13:13:43 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130624131445.6721748448@hg.openjdk.java.net> Changeset: f7573f51e6f9 Author: scolebourne Date: 2013-06-21 17:40 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/f7573f51e6f9 Additional tests and fixes for strict/smart/lenient resolving Issue #318 ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/HijrahChronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/MinguoChronology.java ! src/share/classes/java/time/chrono/ThaiBuddhistChronology.java ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/tck/java/time/chrono/TCKIsoChronology.java ! test/java/time/tck/java/time/chrono/TCKMinguoChronology.java ! test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java Changeset: fbac779a293e Author: scolebourne Date: 2013-06-21 19:00 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/fbac779a293e Enhance Japanese calendar system strict/lenient/smart implementation See #299 ! src/share/classes/java/time/chrono/Chronology.java ! src/share/classes/java/time/chrono/IsoChronology.java ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java From chand.basha at oracle.com Mon Jun 24 10:55:43 2013 From: chand.basha at oracle.com (Chand Basha) Date: Mon, 24 Jun 2013 12:55:43 -0500 Subject: [threeten-dev] Review Request: Hijrah Chronology Tests Message-ID: <51C8881F.7070104@oracle.com> Hi, As per the earlier feedback from Stephen, the tests are updated now. So could you please review the webrev http://cr.openjdk.java.net/~rriggs/webrev-hijrah-calendar-tests-8016898/ and let me know. Thanks, - Basha From roger.riggs at oracle.com Mon Jun 24 12:43:33 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 24 Jun 2013 15:43:33 -0400 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: References: <51C4C2F5.9040609@oracle.com> Message-ID: <51C8A165.7090305@oracle.com> Hi Stephen, On 6/24/2013 7:21 AM, Stephen Colebourne wrote: > And there is a disagreemnet as to the start of the Meiji era. > sun.util.calendar.Era says 1868-01-01, wheras our Japanese Era says 1868-09-08. > Is the old Sun class wrong here? yes, there is an issue for this in JBS 8015478, but I haven't gotten to fixing it. > > Showa is also different by a day. > > The class needs a lot of tidying up I fear. yes it could use some attention. > > Here are some more tests, with bugs commented out. > https://gist.github.com/jodastephen/5849354 These look fine. > > Who is working to fix this class? No one is dedicated; I've been working on identified bugs. Roger > thanks > Stephen > > > > On 24 June 2013 11:26, Stephen Colebourne wrote: >> The patch is fine, except for a cut and paste "Hijrah". >> >> There are lots of issues to work out with Japanese. I'd like to get >> the two patches I put out integrated as well. >> https://github.com/ThreeTen/threeten/issues/299#issuecomment-19831206 >> https://github.com/ThreeTen/threeten/issues/318#issuecomment-19896959 >> >> The public factory methods are also weird too. ofYearDay(int,int) is >> public, unlike other date classes. >> Stephen >> >> >> >> On 21 June 2013 22:17, roger riggs wrote: >>> A number of problems were found with the DAY_OF_YEAR field in >>> JapaneseChronology/Date. >>> The values for the lengthOfYear() and range were incorrectly computed >>> interfering >>> with the operation of get() and with(). >>> >>> The bugs.sun.com issue is: 8017105 >>> >>> >>> Please review and comment: >>> >>> http://cr.openjdk.java.net/~rriggs/webrev-japanese-day-of-year-8017105/ >>> >>> Thanks, Roger >>> >>> From scolebourne at joda.org Mon Jun 24 13:08:30 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 24 Jun 2013 21:08:30 +0100 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: <51C8A165.7090305@oracle.com> References: <51C4C2F5.9040609@oracle.com> <51C8A165.7090305@oracle.com> Message-ID: On 24 June 2013 20:43, roger riggs wrote: > On 6/24/2013 7:21 AM, Stephen Colebourne wrote: >> And there is a disagreemnet as to the start of the Meiji era. >> sun.util.calendar.Era says 1868-01-01, wheras our Japanese Era says >> 1868-09-08. >> Is the old Sun class wrong here? > > yes, there is an issue for this in JBS 8015478, but I haven't gotten to > fixing it. I think its you/Oracle who need to decide on the correct dates for the Japanese era via the I18N team. >> Here are some more tests, with bugs commented out. >> https://gist.github.com/jodastephen/5849354 > These look fine. This test case has a number of commented out lines that I felt should pass, but don't because of era-based issues (misaligned start dates and NPE from missing sun era class). >> Who is working to fix this class? > No one is dedicated; I've been working on identified bugs. I'll leave it up to you/Oracle to fix the tests I commented out and the era stuff. Should I raise other issues in GitHub? Stephen From scolebourne at joda.org Mon Jun 24 13:13:51 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Mon, 24 Jun 2013 21:13:51 +0100 Subject: [threeten-dev] Review Request: Hijrah Chronology Tests In-Reply-To: <51C8881F.7070104@oracle.com> References: <51C8881F.7070104@oracle.com> Message-ID: Fine by me Stephen On 24 June 2013 18:55, Chand Basha wrote: > Hi, > > As per the earlier feedback from Stephen, the tests are updated now. So > could you please review the webrev > http://cr.openjdk.java.net/~rriggs/webrev-hijrah-calendar-tests-8016898/ and > let me know. > > Thanks, > - Basha > From roger.riggs at oracle.com Mon Jun 24 13:16:27 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 24 Jun 2013 20:16:27 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130624201715.CA8E04845C@hg.openjdk.java.net> Changeset: e583e26965a1 Author: rriggs Date: 2013-06-24 16:07 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/e583e26965a1 Bugid: 8017105 JapaneseDate.get(DAY_OF_YEAR) values vs range are inconsistent - Added Override of lengthOfYear to correctly report length - Modified Range/actualRange method to return correct value of length of year - Modiied so that the SEIREKI Era is treated as ISO with respect to lengthOfYear and range() - Added tests to TCKJapaneseChronology to test get() and with DAY_OF_YEAR - Added tests to TestJapaneseChronoImpl to verify that length of year and range values match java.util.Calendar for the Japanese calendar ! src/share/classes/java/time/chrono/JapaneseDate.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java Changeset: ccac263e2ebe Author: rriggs Date: 2013-06-24 16:16 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/ccac263e2ebe Merge ! src/share/classes/java/time/chrono/JapaneseDate.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java From roger.riggs at oracle.com Mon Jun 24 13:23:25 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 24 Jun 2013 16:23:25 -0400 Subject: [threeten-dev] JapaneseDate DAY_OF_YEAR In-Reply-To: References: <51C4C2F5.9040609@oracle.com> <51C8A165.7090305@oracle.com> Message-ID: <51C8AABD.4030502@oracle.com> Hi Stephen, yes, we (Oracle) need to nail down the Japanese calendar details and get them corrected. I've used JBS for some of these that seemed to be implementation bugs and not directly related to the 310 spec. But the bugs.sun.com visibility is poor. Continuing to use Github is better for transparency of JSR 310. I'll create an JBS issue for the commented out test cases. As/if you discover other problems feel free to put them in Github. Roger On 6/24/2013 4:08 PM, Stephen Colebourne wrote: > On 24 June 2013 20:43, roger riggs wrote: >> On 6/24/2013 7:21 AM, Stephen Colebourne wrote: >>> And there is a disagreemnet as to the start of the Meiji era. >>> sun.util.calendar.Era says 1868-01-01, wheras our Japanese Era says >>> 1868-09-08. >>> Is the old Sun class wrong here? >> yes, there is an issue for this in JBS 8015478, but I haven't gotten to >> fixing it. > I think its you/Oracle who need to decide on the correct dates for the > Japanese era via the I18N team. > >>> Here are some more tests, with bugs commented out. >>> https://gist.github.com/jodastephen/5849354 >> These look fine. > This test case has a number of commented out lines that I felt should > pass, but don't because of era-based issues (misaligned start dates > and NPE from missing sun era class). > >>> Who is working to fix this class? >> No one is dedicated; I've been working on identified bugs. > I'll leave it up to you/Oracle to fix the tests I commented out and > the era stuff. > > Should I raise other issues in GitHub? > Stephen From roger.riggs at oracle.com Mon Jun 24 14:25:24 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Mon, 24 Jun 2013 21:25:24 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: BugId: 8016898: Additional tests for Hijrah umAlQura calendar Message-ID: <20130624212546.1CB9848465@hg.openjdk.java.net> Changeset: 62fcc5fe758e Author: rriggs Date: 2013-06-24 17:25 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/62fcc5fe758e BugId: 8016898: Additional tests for Hijrah umAlQura calendar Contributed-by: chand.basha at oracle.com - Moved data driven tests from TCKHijrahChronology to TestUmmAlQuraChronology. ! test/java/time/tck/java/time/chrono/TCKHijrahChronology.java ! test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java From scolebourne at joda.org Wed Jun 26 08:52:52 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Wed, 26 Jun 2013 15:52:52 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130626155345.50F7548558@hg.openjdk.java.net> Changeset: 99ceed2a0265 Author: scolebourne Date: 2013-06-26 16:47 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/99ceed2a0265 Additional Japanese chronology tests See #299 ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java Changeset: 2504d6ba2530 Author: scolebourne Date: 2013-06-26 16:50 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/2504d6ba2530 Merge ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java From roger.riggs at oracle.com Wed Jun 26 12:05:33 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 26 Jun 2013 15:05:33 -0400 Subject: [threeten-dev] Calendar.toZonedDateTime? Message-ID: <51CB3B7D.3040809@oracle.com> Should it be possible to convert any java.util.Calendar object to a ZonedDateTime? The conversion works from an Instant and a TimeZone both found in Calendar. The current placement of toZonedDateTime in GregorianCalendar does not allow it to be used with some calendars, for example a Japanese Imperial Calendar is not of type GregorianCalendar. Could toZonedDateTime be moved up the Calendar? Roger From scolebourne at joda.org Wed Jun 26 12:43:14 2013 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 26 Jun 2013 20:43:14 +0100 Subject: [threeten-dev] Calendar.toZonedDateTime? In-Reply-To: <51CB3B7D.3040809@oracle.com> References: <51CB3B7D.3040809@oracle.com> Message-ID: Its a little hard for me to tell what current methods we have. We seem to have Calendar.toInstant() GregCal.toZDT() GregCal.from(ZDT) I'm surprised I couldn't see a Calendar.from() method. Calendar.from(ChronoZonedDateTime) would make most sense And as suggested, Calendar.toZonedDateTime() returning ChronoZonedDateTime (using covariant return types in GregCal to return ZonedDateTime) It would have to handle chronology to calendar class mapping. In addition, the Calendar.Builder should have a setInstant(Instant) method, as it looks odd to have two setInstant() methods, neither of which actually take an Instant! Stephen On 26 June 2013 20:05, roger riggs wrote: > Should it be possible to convert any java.util.Calendar object to a > ZonedDateTime? > The conversion works from an Instant and a TimeZone both found in Calendar. > > The current placement of toZonedDateTime in GregorianCalendar does not allow > it to be used with some calendars, for example a Japanese Imperial Calendar > is not of type GregorianCalendar. > > Could toZonedDateTime be moved up the Calendar? > > Roger > > From xueming.shen at oracle.com Wed Jun 26 13:56:01 2013 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 26 Jun 2013 13:56:01 -0700 Subject: [threeten-dev] Calendar.toZonedDateTime? In-Reply-To: References: <51CB3B7D.3040809@oracle.com> Message-ID: <51CB5561.3050303@oracle.com> On 06/26/2013 12:43 PM, Stephen Colebourne wrote: > Its a little hard for me to tell what current methods we have. > > We seem to have > Calendar.toInstant() > GregCal.toZDT() > GregCal.from(ZDT) > > I'm surprised I couldn't see a Calendar.from() method. > Calendar.from(ChronoZonedDateTime) would make most sense > The reason we did not do a Calendar<->ChronoZonedDateTime is mainly Calendar is an abstract class and in theory the ChronozonedDateTime can be a non-built-in one. That said, if it's desired that class mapping can be added. -Sherman > And as suggested, > Calendar.toZonedDateTime() returning ChronoZonedDateTime > (using covariant return types in GregCal to return ZonedDateTime) > It would have to handle chronology to calendar class mapping. > > In addition, the Calendar.Builder should have a setInstant(Instant) > method, as it looks odd to have two setInstant() methods, neither of > which actually take an Instant! > > Stephen > > > On 26 June 2013 20:05, roger riggs wrote: >> Should it be possible to convert any java.util.Calendar object to a >> ZonedDateTime? >> The conversion works from an Instant and a TimeZone both found in Calendar. >> >> The current placement of toZonedDateTime in GregorianCalendar does not allow >> it to be used with some calendars, for example a Japanese Imperial Calendar >> is not of type GregorianCalendar. >> >> Could toZonedDateTime be moved up the Calendar? >> >> Roger >> >> From roger.riggs at oracle.com Wed Jun 26 13:57:17 2013 From: roger.riggs at oracle.com (roger riggs) Date: Wed, 26 Jun 2013 16:57:17 -0400 Subject: [threeten-dev] Heads up for code freeze July 10 Message-ID: <51CB55AD.5080106@oracle.com> Hi, The next phase of the SE 8 schedule is "Rampdown Start" (July 18) in which heightened scrutiny is given to changes and the focus is on fixing P1, P2 and P3 issues. Part of the release tracking process involves a JBS bugid will be needed for every commit. Since we have been making API changes there are the usual OpenJDK reviews and additional internal reviews that precede the push to the TL repositories. Changes that have been pushed to the ThreeTen repository by July 10th are included in this milestone. fyi, Roger [1] http://openjdk.java.net/projects/jdk8/milestones From masayoshi.okutsu at oracle.com Wed Jun 26 23:33:15 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 27 Jun 2013 15:33:15 +0900 Subject: [threeten-dev] Calendar.toZonedDateTime? In-Reply-To: References: <51CB3B7D.3040809@oracle.com> Message-ID: <51CBDCAB.1050202@oracle.com> On 6/27/2013 4:43 AM, Stephen Colebourne wrote: > In addition, the Calendar.Builder should have a setInstant(Instant) > method, as it looks odd to have two setInstant() methods, neither of > which actually take an Instant! I proposed Calendar.Builder as a vehicle for JSR310-to-Calendar conversions in addition to addressing the problem of lacking Calendar constructors/factories reported by a developer. But my conversion proposal wasn't well accepted within Oracle. So I proceeded with Calendar.Builder having no JSR 310 conversions. setInstant(Instant) was one of originally proposed methods which were all removed. I didn't change the method name because I wanted to avoid the famous naming confusion -- Time vs Date. That is, Calendar.getTime() returns a Date. Masayoshi From scolebourne at joda.org Thu Jun 27 08:43:10 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Thu, 27 Jun 2013 15:43:10 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Remove public factory on JapaneseDate Message-ID: <20130627154406.DA98D485C3@hg.openjdk.java.net> Changeset: 73a95812438c Author: scolebourne Date: 2013-06-27 11:39 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/73a95812438c Remove public factory on JapaneseDate Change era-based factory to take JapaneseEra, not Era Enhance Javadoc on date and chronology Fix commented out test Add TODOs See #299 Fixes #320 ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java From roger.riggs at oracle.com Fri Jun 28 06:47:21 2013 From: roger.riggs at oracle.com (roger.riggs at oracle.com) Date: Fri, 28 Jun 2013 13:47:21 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 2 new changesets Message-ID: <20130628134759.661BB4863C@hg.openjdk.java.net> Changeset: bc9b3e4ddee5 Author: rriggs Date: 2013-06-28 09:29 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/bc9b3e4ddee5 javadoc fix DateTimeFormatter example ! src/share/classes/java/time/format/DateTimeFormatter.java Changeset: 127b6eb24e72 Author: rriggs Date: 2013-06-28 09:46 -0400 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/127b6eb24e72 Merge From scolebourne at joda.org Fri Jun 28 07:57:41 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Fri, 28 Jun 2013 14:57:41 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: 4 new changesets Message-ID: <20130628145839.7DA3748642@hg.openjdk.java.net> Changeset: 58935f771ca8 Author: scolebourne Date: 2013-06-27 17:24 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/58935f771ca8 Enhance chronology date class now() methods See #324 ! src/share/classes/java/time/chrono/HijrahDate.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! src/share/classes/java/time/chrono/MinguoDate.java ! src/share/classes/java/time/chrono/ThaiBuddhistDate.java Changeset: 7cf25c73ad12 Author: scolebourne Date: 2013-06-27 17:25 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/7cf25c73ad12 Fix ChronoField.INSTANT_SECONDS Javadoc Fixes #323 ! src/share/classes/java/time/temporal/ChronoField.java Changeset: c8db06948326 Author: scolebourne Date: 2013-06-28 15:18 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/c8db06948326 Move ensureChrono() methods to be static on impl classes This is a better place for the code Better casting has also been added See #321 ! src/share/classes/java/time/chrono/ChronoDateImpl.java ! src/share/classes/java/time/chrono/ChronoLocalDate.java ! src/share/classes/java/time/chrono/ChronoLocalDateTime.java ! src/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java ! src/share/classes/java/time/chrono/ChronoZonedDateTime.java ! src/share/classes/java/time/chrono/ChronoZonedDateTimeImpl.java ! src/share/classes/java/time/chrono/Chronology.java Changeset: 115ea789ba58 Author: scolebourne Date: 2013-06-28 15:56 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/115ea789ba58 Merge From scolebourne at joda.org Fri Jun 28 08:05:40 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Fri, 28 Jun 2013 15:05:40 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Fix method parameter ordering Message-ID: <20130628150603.03D0A48644@hg.openjdk.java.net> Changeset: cfba4fe9fdc0 Author: scolebourne Date: 2013-06-28 16:05 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/cfba4fe9fdc0 Fix method parameter ordering See #299 ! src/share/classes/java/time/chrono/JapaneseChronology.java From scolebourne at joda.org Sat Jun 29 02:31:48 2013 From: scolebourne at joda.org (scolebourne at joda.org) Date: Sat, 29 Jun 2013 09:31:48 +0000 Subject: [threeten-dev] hg: threeten/threeten/jdk: Remove support for Japanese week aligned week fields Message-ID: <20130629093212.7CBC94868C@hg.openjdk.java.net> Changeset: 4467c647ade9 Author: scolebourne Date: 2013-06-29 10:31 +0100 URL: http://hg.openjdk.java.net/threeten/threeten/jdk/rev/4467c647ade9 Remove support for Japanese week aligned week fields See #319 ! src/share/classes/java/time/chrono/JapaneseChronology.java ! src/share/classes/java/time/chrono/JapaneseDate.java ! test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java ! test/java/time/test/java/time/chrono/TestJapaneseChronology.java