threeten-develop Mailing List for threeten
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: Stephen C. <sco...@jo...> - 2015-01-17 22:52:30
|
I haven't experimented with it, but in theory additional calendar resource data can be added. See http://docs.oracle.com/javase/8/docs/technotes/guides/intl/enhancements.8.html#api http://docs.oracle.com/javase/8/docs/api/java/util/spi/CalendarNameProvider.html You know as much as I do though... Stephen On 16 January 2015 at 10:49, Carlo Dapor <ca...@gm...> wrote: > Hello 3-teners > > > I developed a calendar which works with 13 months by 28 days; the > months are the same ones found in the Gregorian calendar. > Except for an extra month placed between June and July, called Sol. > > A simple code snippet to illustrate what I want to achieve: > > public class NotTestIfc { > public static void main(final String[] args) { > //Locale locale = Locale.forLanguageTag("en-US-u-ca-ifc"); > Locale locale = Locale.forLanguageTag("en-u-ca-ifc"); > System.out.println(locale.toString()); > //Locale.setDefault(locale); > > InternationalFixedDate date = InternationalFixedDate.of(2013, 13, 1); > //InternationalFixedDate date = InternationalFixedDate.of(2013, 12, 1); > System.out.println(date); > > Chronology chrono = Chronology.ofLocale(locale); > System.out.println(chrono); > > DateTimeFormatter formatter = > DateTimeFormatter > //.ofPattern("MMMM dd yyyy") > .ofLocalizedDate(FormatStyle.LONG) > .withLocale(locale) > .withChronology(chrono); > String s = formatter.format(date); > System.out.println(s); > String s2 = date.format(formatter); > > System.out.println(s2); > } > } > > The code should print "December 01 2013", but instead prints " 01 2013". > If the date was 2013, 12, 1, then December 01 2013 is printed, which > is incorrect. > > You need to clone https://github.com/catull/threeten-extra.git to see > InternationalFixedDate / InternationalFixedChronology etc. > > Providing my own sun.text.resources.en.FormatDate_en class as .. > > package sun.text.resources.en; > > import java.util.ListResourceBundle; > > public class FormatData_en extends ListResourceBundle { > @Override > protected Object[][] getContents() { > return new Object[][] { > { "NumberPatterns", > new String[] { > "#,##0.###;-#,##0.###", // decimal pattern > "\u00A4#,##0.00;-\u00A4#,##0.00", // > currency pattern > "#,##0%" // percent pattern > } > }, > { "DateTimePatternChars","GyMdkHmsSEDFwWahKzZ" }, > { "MonthNames", > new String[] { "January", "February", "March", > "April", "May", "June", "Sol", "July", "August", "September", > "October", "November", "December" } }, > { "MonthAbbreviations", > new String[] { "Jan", "Feb", "Mar", "Apr", > "May", "Jun", "Sol", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" } > } > > }; > } > } > > > ... changes nothing as far as date printing is concerned. > > What am I missing ? > > > Regards, > -- > Carlo > > ------------------------------------------------------------------------------ > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashburn. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant. > http://p.sf.net/sfu/gigenet > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Carlo D. <ca...@gm...> - 2015-01-16 10:49:46
|
Hello 3-teners I developed a calendar which works with 13 months by 28 days; the months are the same ones found in the Gregorian calendar. Except for an extra month placed between June and July, called Sol. A simple code snippet to illustrate what I want to achieve: public class NotTestIfc { public static void main(final String[] args) { //Locale locale = Locale.forLanguageTag("en-US-u-ca-ifc"); Locale locale = Locale.forLanguageTag("en-u-ca-ifc"); System.out.println(locale.toString()); //Locale.setDefault(locale); InternationalFixedDate date = InternationalFixedDate.of(2013, 13, 1); //InternationalFixedDate date = InternationalFixedDate.of(2013, 12, 1); System.out.println(date); Chronology chrono = Chronology.ofLocale(locale); System.out.println(chrono); DateTimeFormatter formatter = DateTimeFormatter //.ofPattern("MMMM dd yyyy") .ofLocalizedDate(FormatStyle.LONG) .withLocale(locale) .withChronology(chrono); String s = formatter.format(date); System.out.println(s); String s2 = date.format(formatter); System.out.println(s2); } } The code should print "December 01 2013", but instead prints " 01 2013". If the date was 2013, 12, 1, then December 01 2013 is printed, which is incorrect. You need to clone https://github.com/catull/threeten-extra.git to see InternationalFixedDate / InternationalFixedChronology etc. Providing my own sun.text.resources.en.FormatDate_en class as .. package sun.text.resources.en; import java.util.ListResourceBundle; public class FormatData_en extends ListResourceBundle { @Override protected Object[][] getContents() { return new Object[][] { { "NumberPatterns", new String[] { "#,##0.###;-#,##0.###", // decimal pattern "\u00A4#,##0.00;-\u00A4#,##0.00", // currency pattern "#,##0%" // percent pattern } }, { "DateTimePatternChars","GyMdkHmsSEDFwWahKzZ" }, { "MonthNames", new String[] { "January", "February", "March", "April", "May", "June", "Sol", "July", "August", "September", "October", "November", "December" } }, { "MonthAbbreviations", new String[] { "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Sol", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" } } }; } } ... changes nothing as far as date printing is concerned. What am I missing ? Regards, -- Carlo |
From: Stephen I. <clo...@ou...> - 2014-11-12 10:03:37
|
I have a question; since there were a multitude of different cutover dates, depending on the country (some of which don’t exist anymore…) and religious affiliation, is the plan to do a different cutover for each such case? Would a generic cutover calendar be possible, or does stuff like Sweden (?!? - oi, seriously?) cause too much of a problem? Stephen A. Imhoff |
From: Stephen I. <clo...@ou...> - 2014-11-04 22:51:16
|
It does, thanks. That’s pretty much what I was expecting, it just ends up being more work. I may have a pull request for this calendar later this week. Stephen A. Imhoff From: Stephen Colebourne Sent: Wednesday, November 5, 2014 03:32 To: thr...@li... On 2 November 2014 23:58, Stephen Imhoff <clo...@ou...> wrote: > Well, for plus/minus (and day-of-year) that’s what I did (because it’s > closest to the behavior seen for February 29th). > But things get a little strange with until(…), because of how St. Tib’s Day > sits outside of the normal day-of-month/week count. You don’t have the > problem with the Gregorian/ISO leap day because it’s considered part of the > normal count of days, and it’s added at the end of the month. In the > Discordian calendar, the 59th and 60th days of the first month explicitly > stay those days of the month(and 4th and 5th day of the week, respectively), > even when St. Tib’s Day gets inserted between them. So my question was > really more about how much of an effect to make it have. > ie -> From 1/55 to St. Tib’s Day. This is a 5-day difference (no problem > with ChronoUnit.DAYS). However, the next same day-of-week is actually 1/60, > the day after St. Tib’s Day. Adding 1 week to 1/55 yields 1/60 always. > Subtracting 1 week from 1/60 and St. Tib’s Day yields 1/55 in both cases > (because of coercing St. Tib’s Day to 1/60 first), but when dealing with > until(…) we haven’t gotten to the same-of-unit yet. So do I silently coerce > it for until(…) too (easy), or go for a stricter, more “correct” > interpretation? 1/55 plus 5 days = StTibs 1/54 plus 1 week = 1/59 1/55 plus 1 week = 1/60 (plus week/month/year never lands on StTibs) from 1/55 until StTibs in days = 5 from 1/55 until 1/60 in days = 6 from 1/55 until StTibs in weeks = 0 from 1/55 until 1/60 in weeks = 1 But I'm not sure if that answers your question! >> WeekFields is entirely based on 7 day weeks, so I suspect its not >> worth trying to be clever there, > > Well, I could tell it’s based on 7-day weeks, my question was more about how > it was supposed to interact with calendars without 7-day weeks. > My initial assumption was that it should return the actual ISO day-of-week > (based on Epoch Day or something), but it seems to be returning the local > day-of-week (ie, 1-5 for the Discordian Calendar) instead. Is it just not > supported for calendars without 7-day weeks (and if so, should it throw an > error), or was my initial thought correct, and it should return the actual > ISO day-of-week? I think its just not supported. Stephen ------------------------------------------------------------------------------ _______________________________________________ threeten-develop mailing list thr...@li... https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2014-11-04 18:32:35
|
On 2 November 2014 23:58, Stephen Imhoff <clo...@ou...> wrote: > Well, for plus/minus (and day-of-year) that’s what I did (because it’s > closest to the behavior seen for February 29th). > But things get a little strange with until(…), because of how St. Tib’s Day > sits outside of the normal day-of-month/week count. You don’t have the > problem with the Gregorian/ISO leap day because it’s considered part of the > normal count of days, and it’s added at the end of the month. In the > Discordian calendar, the 59th and 60th days of the first month explicitly > stay those days of the month(and 4th and 5th day of the week, respectively), > even when St. Tib’s Day gets inserted between them. So my question was > really more about how much of an effect to make it have. > ie -> From 1/55 to St. Tib’s Day. This is a 5-day difference (no problem > with ChronoUnit.DAYS). However, the next same day-of-week is actually 1/60, > the day after St. Tib’s Day. Adding 1 week to 1/55 yields 1/60 always. > Subtracting 1 week from 1/60 and St. Tib’s Day yields 1/55 in both cases > (because of coercing St. Tib’s Day to 1/60 first), but when dealing with > until(…) we haven’t gotten to the same-of-unit yet. So do I silently coerce > it for until(…) too (easy), or go for a stricter, more “correct” > interpretation? 1/55 plus 5 days = StTibs 1/54 plus 1 week = 1/59 1/55 plus 1 week = 1/60 (plus week/month/year never lands on StTibs) from 1/55 until StTibs in days = 5 from 1/55 until 1/60 in days = 6 from 1/55 until StTibs in weeks = 0 from 1/55 until 1/60 in weeks = 1 But I'm not sure if that answers your question! >> WeekFields is entirely based on 7 day weeks, so I suspect its not >> worth trying to be clever there, > > Well, I could tell it’s based on 7-day weeks, my question was more about how > it was supposed to interact with calendars without 7-day weeks. > My initial assumption was that it should return the actual ISO day-of-week > (based on Epoch Day or something), but it seems to be returning the local > day-of-week (ie, 1-5 for the Discordian Calendar) instead. Is it just not > supported for calendars without 7-day weeks (and if so, should it throw an > error), or was my initial thought correct, and it should return the actual > ISO day-of-week? I think its just not supported. Stephen |
From: Stephen I. <clo...@ou...> - 2014-11-03 00:33:40
|
Well, for plus/minus (and day-of-year) that’s what I did (because it’s closest to the behavior seen for February 29th). But things get a little strange with until(…), because of how St. Tib’s Day sits outside of the normal day-of-month/week count. You don’t have the problem with the Gregorian/ISO leap day because it’s considered part of the normal count of days, and it’s added at the end of the month. In the Discordian calendar, the 59th and 60th days of the first month explicitly stay those days of the month(and 4th and 5th day of the week, respectively), even when St. Tib’s Day gets inserted between them. So my question was really more about how much of an effect to make it have. ie -> From 1/55 to St. Tib’s Day. This is a 5-day difference (no problem with ChronoUnit.DAYS). However, the next same day-of-week is actually 1/60, the day after St. Tib’s Day. Adding 1 week to 1/55 yields 1/60 always. Subtracting 1 week from 1/60 and St. Tib’s Day yields 1/55 in both cases (because of coercing St. Tib’s Day to 1/60 first), but when dealing with until(…) we haven’t gotten to the same-of-unit yet. So do I silently coerce it for until(…) too (easy), or go for a stricter, more “correct” interpretation? > WeekFields is entirely based on 7 day weeks, so I suspect its not > worth trying to be clever there, Well, I could tell it’s based on 7-day weeks, my question was more about how it was supposed to interact with calendars without 7-day weeks. My initial assumption was that it should return the actual ISO day-of-week (based on Epoch Day or something), but it seems to be returning the local day-of-week (ie, 1-5 for the Discordian Calendar) instead. Is it just not supported for calendars without 7-day weeks (and if so, should it throw an error), or was my initial thought correct, and it should return the actual ISO day-of-week? Stephen A. Imhoff From: Stephen Colebourne Sent: Monday, November 3, 2014 06:12 To: thr...@li... On 27 October 2014 09:58, Stephen Imhoff <xan...@ho...> wrote: > So, I’ve been working on implementing the Discordian calendar too, and I’ve > run into a definition problem. I have the thing mostly working, but I’m > undecided on what behavior should be in one case - the until(…) method (when > dealing with St. Tib’s Day). > > Adding/subtracting a unit of time? have resolvePrevious(…) shove it to the > 60th day of the month. In cases of weeks, do that first (make it work as if > the 5th day of the week, too). Slightly awkward, but probably closest to > what people would normally expect. > > But what do I do with until(…)? > If I subtract 1 month from St. Tib’s Day, I get the same result as if it was > the 60th day of the month (previous year, 5th month, 60th day). Add 1 month > to this previous nets me the 60th day of the month again. But is St. Tib’s > Day an outlier, or no? Now, clearly, from the 59th of the previous to St. > Tib’s Day is 1 month (as we’ll have passed the 59th in the 1st month to get > there), but we won’t have passed the 60th in the 1st month when starting > from the 60th of the previous. A similar problem happens when starting from > the 2nd month and subtracting. > Any thoughts? I can implement anything, but feel a bit stuck with what the > best option should probably be. Subtract 1 year from Day-Of-Year 366 in 2012 gets you Day-Of-Year 365 in 2011. Adding a year gets you Day-Of-Year 365 in 2012. So, no round trip. As such St'Tibs minus one month, plus one month is not round trippable. The rule would be that adding/subtracting days the logic "sees" StTibs, but adding/subtracting months or larger does not "see" StTibs (unless starting on StTibs, where you'd resolve to the 60th). > Also, my read on stuff like: {2014, 5, 26, WeekFields.ISO.dayOfWeek(), 5} > was that get(…) should return the ISO day-of-week, not local-day-of-week. > Currently the default (not overridden) behavior seems to be returning > local-day-of-week; is that correct, or should I investigate/override for > behavior? WeekFields is entirely based on 7 day weeks, so I suspect its not worth trying to be clever there, Key to StTibs is what numbers to assign to StTibs day for day-of-week and day-of-month. I think that zero is a reasonable value in both cases, as it is outside the normal pattern of days. I would say that day-of-year is a more traditional count which changes as a result of the extra day. Stephen ------------------------------------------------------------------------------ _______________________________________________ threeten-develop mailing list thr...@li... https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2014-11-02 21:12:01
|
On 27 October 2014 09:58, Stephen Imhoff <xan...@ho...> wrote: > So, I’ve been working on implementing the Discordian calendar too, and I’ve > run into a definition problem. I have the thing mostly working, but I’m > undecided on what behavior should be in one case - the until(…) method (when > dealing with St. Tib’s Day). > > Adding/subtracting a unit of time? have resolvePrevious(…) shove it to the > 60th day of the month. In cases of weeks, do that first (make it work as if > the 5th day of the week, too). Slightly awkward, but probably closest to > what people would normally expect. > > But what do I do with until(…)? > If I subtract 1 month from St. Tib’s Day, I get the same result as if it was > the 60th day of the month (previous year, 5th month, 60th day). Add 1 month > to this previous nets me the 60th day of the month again. But is St. Tib’s > Day an outlier, or no? Now, clearly, from the 59th of the previous to St. > Tib’s Day is 1 month (as we’ll have passed the 59th in the 1st month to get > there), but we won’t have passed the 60th in the 1st month when starting > from the 60th of the previous. A similar problem happens when starting from > the 2nd month and subtracting. > Any thoughts? I can implement anything, but feel a bit stuck with what the > best option should probably be. Subtract 1 year from Day-Of-Year 366 in 2012 gets you Day-Of-Year 365 in 2011. Adding a year gets you Day-Of-Year 365 in 2012. So, no round trip. As such St'Tibs minus one month, plus one month is not round trippable. The rule would be that adding/subtracting days the logic "sees" StTibs, but adding/subtracting months or larger does not "see" StTibs (unless starting on StTibs, where you'd resolve to the 60th). > Also, my read on stuff like: {2014, 5, 26, WeekFields.ISO.dayOfWeek(), 5} > was that get(…) should return the ISO day-of-week, not local-day-of-week. > Currently the default (not overridden) behavior seems to be returning > local-day-of-week; is that correct, or should I investigate/override for > behavior? WeekFields is entirely based on 7 day weeks, so I suspect its not worth trying to be clever there, Key to StTibs is what numbers to assign to StTibs day for day-of-week and day-of-month. I think that zero is a reasonable value in both cases, as it is outside the normal pattern of days. I would say that day-of-year is a more traditional count which changes as a result of the extra day. Stephen |
From: Stephen I. <xan...@ho...> - 2014-10-27 10:00:35
|
So, I’ve been working on implementing the Discordian calendar too, and I’ve run into a definition problem. I have the thing mostly working, but I’m undecided on what behavior should be in one case - the until(…) method (when dealing with St. Tib’s Day). Adding/subtracting a unit of time? have resolvePrevious(…) shove it to the 60th day of the month. In cases of weeks, do that first (make it work as if the 5th day of the week, too). Slightly awkward, but probably closest to what people would normally expect. But what do I do with until(…)? If I subtract 1 month from St. Tib’s Day, I get the same result as if it was the 60th day of the month (previous year, 5th month, 60th day). Add 1 month to this previous nets me the 60th day of the month again. But is St. Tib’s Day an outlier, or no? Now, clearly, from the 59th of the previous to St. Tib’s Day is 1 month (as we’ll have passed the 59th in the 1st month to get there), but we won’t have passed the 60th in the 1st month when starting from the 60th of the previous. A similar problem happens when starting from the 2nd month and subtracting. Any thoughts? I can implement anything, but feel a bit stuck with what the best option should probably be. Also, my read on stuff like: {2014, 5, 26, WeekFields.ISO.dayOfWeek(), 5} was that get(…) should return the ISO day-of-week, not local-day-of-week. Currently the default (not overridden) behavior seems to be returning local-day-of-week; is that correct, or should I investigate/override for behavior? Code is on GitHub, if you want to read that too. Stephen A. Imhoff |
From: roger r. <rog...@or...> - 2014-10-09 19:06:58
|
Hi, Just a note, a LocalDate is a single point on the year scale. But on the full timeline it represents a segment having a start and an end. It is not the same as LocalDate.atTime(MIDNIGHT). It would also have a start and end expressed as a pair of LocalDateTimes. To get a span of machine equivalent to Instants would require a timezone. In that context the segment (depending on the tzdata) might be 23 hours or 25 hours (typically). Not so simple or intuitive to be baked into the API without a specific use case. Roger On 10/8/2014 6:09 PM, Jesper Steen Møller wrote: >> On 08/10/2014, at 21.15, Ian Brandt <ia...@ia...> wrote: >> >> >> Hi Roger and Stephen, >> >> Thanks for the quick replies. It is good to know about the parseDefaulting() API. I hadn’t found my way to that yet. >> >> I didn’t mean for my original post to be a question per se, but more of a bug report or feature request depending. With regard to making up a time out of thin air, my point is that the precedent in the Java platform is to do just that, and doing so is ok and useful. Here are some examples: >> > In a great many contexts, a date by itself refers to something deliberately without time and tine zone (LocalDate), whereas a date with a time often need a time zone to retain it's meaning, unless you are really referring to some ideal point in time on a specific date applicable to all time zones, or are in fact implicitly referring to a specific time zone from context. > > Blurring the destinction between LocalDate and LocalDateTime is thus dangerous. > > To wit: The java.util.Date constructor with year,month,day is deprecated, since it will stick the time zone in there. > > If you are after a point in time with an indication of applicability, go for ZonedDateTime or OffsetDateTime. If you need to record the point in time, use Instant. > > >> Are dates and date-times not simply two ways of representing values on a timeline, with the latter being of higher precision? > I understand your point, but I still offer 'no', they're seperate concepts. > >> In that sense are they not like integers and rational numbers on the number line? As shown in the above example Java automatically widens ints to floats (even in some cases where information is lost: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2). I’ve asked for a number representation with higher precision than the one I started with, and values of 0 are defaulted for the tenths, hundredths, thousandths and ten-thousandths. With: >> >> LocalDateTime.parse("24-Aug-2009", DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US)) >> >> …I’m asking for a time representation with higher precision than the one I started with, and defaulting the hours, minutes, seconds and nanoseconds to 0 seems perfectly reasonable to me. I think java.time would be more consistent with the rest of the platform (i.e. intuitive) and more convenient if that was the default behavior. >> > Perhaps you need a ZonedDateTime with a Duration to indicate the precision of that point in time? > >> Best, >> >> Ian > -Jesper > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Jesper S. M. <je...@se...> - 2014-10-08 22:40:51
|
> On 08/10/2014, at 21.15, Ian Brandt <ia...@ia...> wrote: > > > Hi Roger and Stephen, > > Thanks for the quick replies. It is good to know about the parseDefaulting() API. I hadn’t found my way to that yet. > > I didn’t mean for my original post to be a question per se, but more of a bug report or feature request depending. With regard to making up a time out of thin air, my point is that the precedent in the Java platform is to do just that, and doing so is ok and useful. Here are some examples: > In a great many contexts, a date by itself refers to something deliberately without time and tine zone (LocalDate), whereas a date with a time often need a time zone to retain it's meaning, unless you are really referring to some ideal point in time on a specific date applicable to all time zones, or are in fact implicitly referring to a specific time zone from context. Blurring the destinction between LocalDate and LocalDateTime is thus dangerous. To wit: The java.util.Date constructor with year,month,day is deprecated, since it will stick the time zone in there. If you are after a point in time with an indication of applicability, go for ZonedDateTime or OffsetDateTime. If you need to record the point in time, use Instant. > Are dates and date-times not simply two ways of representing values on a timeline, with the latter being of higher precision? I understand your point, but I still offer 'no', they're seperate concepts. > In that sense are they not like integers and rational numbers on the number line? As shown in the above example Java automatically widens ints to floats (even in some cases where information is lost: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2). I’ve asked for a number representation with higher precision than the one I started with, and values of 0 are defaulted for the tenths, hundredths, thousandths and ten-thousandths. With: > > LocalDateTime.parse("24-Aug-2009", DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US)) > > …I’m asking for a time representation with higher precision than the one I started with, and defaulting the hours, minutes, seconds and nanoseconds to 0 seems perfectly reasonable to me. I think java.time would be more consistent with the rest of the platform (i.e. intuitive) and more convenient if that was the default behavior. > Perhaps you need a ZonedDateTime with a Duration to indicate the precision of that point in time? > Best, > > Ian -Jesper |
From: Stephen C. <sco...@jo...> - 2014-10-08 21:56:13
|
To set your expectations, I don't have any desire to change the way this currently operates. Widening and other implicit conversions are often thought of as a mistake (and Scala has shown how bad a mistake they can be). While in this case, the risks would be low, it also sends out a message that dates and times are interchangeable which the new java.time does not wish to do. And it is possible to argue beyond just hours - for example should you be able to create a date if only supplying the year and month? or just the month? The old DateFormat did allow those, and I consider that a flaw, not a feature. So yes, java.time is stricter than DateFormat, but this was a deliberate design decision. Stephen On 8 October 2014 20:15, Ian Brandt <ia...@ia...> wrote: > > Hi Roger and Stephen, > > Thanks for the quick replies. It is good to know about the parseDefaulting() API. I hadn’t found my way to that yet. > > I didn’t mean for my original post to be a question per se, but more of a bug report or feature request depending. With regard to making up a time out of thin air, my point is that the precedent in the Java platform is to do just that, and doing so is ok and useful. Here are some examples: > > import java.math.*; > import java.text.*; > import java.util.*; > > public class AutomaticWideningTest { > public static void main(String[] args) throws Exception { > > int myInt = 1; > float myFloat = myInt; > System.out.printf(“%.4f\n”, myFloat); // 1.0000 > > BigDecimal scaleZero = new BigDecimal(1); > BigDecimal scaleFour = scaleZero.setScale(4); > System.out.println(scaleFour); // 1.0000 > > Date dateTime = new SimpleDateFormat("yyyy-MM-dd").parse("2014-10-08"); > System.out.println(dateTime); // Wed Oct 08 00:00:00 PDT 2014 > } > } > > Are dates and date-times not simply two ways of representing values on a timeline, with the latter being of higher precision? In that sense are they not like integers and rational numbers on the number line? As shown in the above example Java automatically widens ints to floats (even in some cases where information is lost: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2). I’ve asked for a number representation with higher precision than the one I started with, and values of 0 are defaulted for the tenths, hundredths, thousandths and ten-thousandths. With: > > LocalDateTime.parse("24-Aug-2009", DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US)) > > …I’m asking for a time representation with higher precision than the one I started with, and defaulting the hours, minutes, seconds and nanoseconds to 0 seems perfectly reasonable to me. I think java.time would be more consistent with the rest of the platform (i.e. intuitive) and more convenient if that was the default behavior. > > Best, > > Ian > > > On Oct 8, 2014, at 1:15 AM, Stephen Colebourne <sco...@jo...> wrote: > >> Just to note that if you create a DateTimeFormatterBuilder and use >> parseDefaulting() you can get this to work. >> >> http://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatterBuilder.html#parseDefaulting-java.time.temporal.TemporalField-long- >> >> The standard implementation will not make up a time out of thin air >> (it will default minutes, seconds and nanoseconds to zero, but not >> hours). >> >> Stephen >> >> >> >> >> On 8 October 2014 05:36, Roger Riggs <Rog...@or...> wrote: >>> Hi Ian, >>> >>> I think you answered your own question. If the pattern and the input >>> provide >>> only date information then only a LocalDate can be parsed. >>> >>> The nested exception says "Unable to obtain LocalTime from TemporalAccessor" >>> that indicates there is no time information in the input and so a LocalTime >>> cannot be created. Parsing can ignore extra information from the input >>> but cannot fabricate fields from no data. >>> >>> Regards, Roger >>> >>> >>> >>> On 10/7/14 6:56 PM, Ian Brandt wrote: >>> >>> Greetings, >>> >>> Feel free to direct me to another venue if this is the wrong place to post >>> this. I don’t have author status on the JDK Bug System, so I can’t file an >>> issue there. >>> >>> The new java.time API allows for the creation of a DateTimeFormatter pattern >>> that only includes a date portion; however, LocalDateTime fails to parse >>> such a pattern with a rather cryptic error: >>> >>> LocalDateTimeParseDateTest.java >>> ——— >>> import java.time.*; >>> import java.time.format.*; >>> import java.util.*; >>> >>> public class LocalDateTimeParseDateTest { >>> public static void main(String[] args) { >>> String dateString = "24-Aug-2009"; >>> DateTimeFormatter dateTimeFormatter = >>> DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US); >>> LocalDateTime.parse(dateString, dateTimeFormatter); >>> } >>> } >>> ——— >>> >>> $ java -version >>> java version "1.8.0_20" >>> Java(TM) SE Runtime Environment (build 1.8.0_20-b26) >>> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) >>> >>> $ java LocalDateTimeParseDateTest >>> Exception in thread "main" java.time.format.DateTimeParseException: Text >>> '24-Aug-2009' could not be parsed: Unable to obtain LocalDateTime from >>> TemporalAccessor: {},ISO resolved to 2009-08-24 of type >>> java.time.format.Parsed >>> at >>> java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1918) >>> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1853) >>> at java.time.LocalDateTime.parse(LocalDateTime.java:492) >>> at LocalDateTimeParseDateTest.main(LocalDateTimeParseDateTest.java:9) >>> Caused by: java.time.DateTimeException: Unable to obtain LocalDateTime from >>> TemporalAccessor: {},ISO resolved to 2009-08-24 of type >>> java.time.format.Parsed >>> at java.time.LocalDateTime.from(LocalDateTime.java:461) >>> at java.time.LocalDateTime$$Lambda$7/245257410.queryFrom(Unknown Source) >>> at java.time.format.Parsed.query(Parsed.java:226) >>> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1849) >>> ... 2 more >>> Caused by: java.time.DateTimeException: Unable to obtain LocalTime from >>> TemporalAccessor: {},ISO resolved to 2009-08-24 of type >>> java.time.format.Parsed >>> at java.time.LocalTime.from(LocalTime.java:409) >>> at java.time.LocalDateTime.from(LocalDateTime.java:457) >>> ... 5 more >>> >>> >>> It works fine with “LocalDate.parse(dateString, dateTimeFormatter)”. I also >>> noticed it works for LocalDate with a pattern and input string that include >>> a time portion. To summarize: >>> >>> - LocalDate can use a DateTimeFormatter to parse even with a pattern that >>> includes a time portion. >>> - LocalDateTime cannot use a DateTimeFormatter to parse unless the pattern >>> includes a time portion. >>> >>> So a “narrowing conversion” from date-time to date works, but a “widening >>> conversion” from date to date-time does not. I’m sure it’s debatable, but >>> that seems a bit backwards to me. I believe a Joda DateTimeFormatter with a >>> date-only pattern successfully parses a Joda DateTime by just assuming >>> start-of-day for the time portion. I think it would be an improvement if >>> java.time followed suit. >>> >>> Best regards, >>> >>> Ian >>> ------------------------------------------------------------------------------ >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> threeten-develop mailing list >>> thr...@li... >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >>> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> threeten-develop mailing list >>> thr...@li... >>> https://lists.sourceforge.net/lists/listinfo/threeten-develop >>> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Ian B. <ia...@ia...> - 2014-10-08 19:45:13
|
Hi Roger and Stephen, Thanks for the quick replies. It is good to know about the parseDefaulting() API. I hadn’t found my way to that yet. I didn’t mean for my original post to be a question per se, but more of a bug report or feature request depending. With regard to making up a time out of thin air, my point is that the precedent in the Java platform is to do just that, and doing so is ok and useful. Here are some examples: import java.math.*; import java.text.*; import java.util.*; public class AutomaticWideningTest { public static void main(String[] args) throws Exception { int myInt = 1; float myFloat = myInt; System.out.printf(“%.4f\n”, myFloat); // 1.0000 BigDecimal scaleZero = new BigDecimal(1); BigDecimal scaleFour = scaleZero.setScale(4); System.out.println(scaleFour); // 1.0000 Date dateTime = new SimpleDateFormat("yyyy-MM-dd").parse("2014-10-08"); System.out.println(dateTime); // Wed Oct 08 00:00:00 PDT 2014 } } Are dates and date-times not simply two ways of representing values on a timeline, with the latter being of higher precision? In that sense are they not like integers and rational numbers on the number line? As shown in the above example Java automatically widens ints to floats (even in some cases where information is lost: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.2). I’ve asked for a number representation with higher precision than the one I started with, and values of 0 are defaulted for the tenths, hundredths, thousandths and ten-thousandths. With: LocalDateTime.parse("24-Aug-2009", DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US)) …I’m asking for a time representation with higher precision than the one I started with, and defaulting the hours, minutes, seconds and nanoseconds to 0 seems perfectly reasonable to me. I think java.time would be more consistent with the rest of the platform (i.e. intuitive) and more convenient if that was the default behavior. Best, Ian On Oct 8, 2014, at 1:15 AM, Stephen Colebourne <sco...@jo...> wrote: > Just to note that if you create a DateTimeFormatterBuilder and use > parseDefaulting() you can get this to work. > > http://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatterBuilder.html#parseDefaulting-java.time.temporal.TemporalField-long- > > The standard implementation will not make up a time out of thin air > (it will default minutes, seconds and nanoseconds to zero, but not > hours). > > Stephen > > > > > On 8 October 2014 05:36, Roger Riggs <Rog...@or...> wrote: >> Hi Ian, >> >> I think you answered your own question. If the pattern and the input >> provide >> only date information then only a LocalDate can be parsed. >> >> The nested exception says "Unable to obtain LocalTime from TemporalAccessor" >> that indicates there is no time information in the input and so a LocalTime >> cannot be created. Parsing can ignore extra information from the input >> but cannot fabricate fields from no data. >> >> Regards, Roger >> >> >> >> On 10/7/14 6:56 PM, Ian Brandt wrote: >> >> Greetings, >> >> Feel free to direct me to another venue if this is the wrong place to post >> this. I don’t have author status on the JDK Bug System, so I can’t file an >> issue there. >> >> The new java.time API allows for the creation of a DateTimeFormatter pattern >> that only includes a date portion; however, LocalDateTime fails to parse >> such a pattern with a rather cryptic error: >> >> LocalDateTimeParseDateTest.java >> ——— >> import java.time.*; >> import java.time.format.*; >> import java.util.*; >> >> public class LocalDateTimeParseDateTest { >> public static void main(String[] args) { >> String dateString = "24-Aug-2009"; >> DateTimeFormatter dateTimeFormatter = >> DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US); >> LocalDateTime.parse(dateString, dateTimeFormatter); >> } >> } >> ——— >> >> $ java -version >> java version "1.8.0_20" >> Java(TM) SE Runtime Environment (build 1.8.0_20-b26) >> Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) >> >> $ java LocalDateTimeParseDateTest >> Exception in thread "main" java.time.format.DateTimeParseException: Text >> '24-Aug-2009' could not be parsed: Unable to obtain LocalDateTime from >> TemporalAccessor: {},ISO resolved to 2009-08-24 of type >> java.time.format.Parsed >> at >> java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1918) >> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1853) >> at java.time.LocalDateTime.parse(LocalDateTime.java:492) >> at LocalDateTimeParseDateTest.main(LocalDateTimeParseDateTest.java:9) >> Caused by: java.time.DateTimeException: Unable to obtain LocalDateTime from >> TemporalAccessor: {},ISO resolved to 2009-08-24 of type >> java.time.format.Parsed >> at java.time.LocalDateTime.from(LocalDateTime.java:461) >> at java.time.LocalDateTime$$Lambda$7/245257410.queryFrom(Unknown Source) >> at java.time.format.Parsed.query(Parsed.java:226) >> at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1849) >> ... 2 more >> Caused by: java.time.DateTimeException: Unable to obtain LocalTime from >> TemporalAccessor: {},ISO resolved to 2009-08-24 of type >> java.time.format.Parsed >> at java.time.LocalTime.from(LocalTime.java:409) >> at java.time.LocalDateTime.from(LocalDateTime.java:457) >> ... 5 more >> >> >> It works fine with “LocalDate.parse(dateString, dateTimeFormatter)”. I also >> noticed it works for LocalDate with a pattern and input string that include >> a time portion. To summarize: >> >> - LocalDate can use a DateTimeFormatter to parse even with a pattern that >> includes a time portion. >> - LocalDateTime cannot use a DateTimeFormatter to parse unless the pattern >> includes a time portion. >> >> So a “narrowing conversion” from date-time to date works, but a “widening >> conversion” from date to date-time does not. I’m sure it’s debatable, but >> that seems a bit backwards to me. I believe a Joda DateTimeFormatter with a >> date-only pattern successfully parses a Joda DateTime by just assuming >> start-of-day for the time portion. I think it would be an improvement if >> java.time followed suit. >> >> Best regards, >> >> Ian >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> >> >> >> ------------------------------------------------------------------------------ >> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer >> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports >> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper >> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer >> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk >> _______________________________________________ >> threeten-develop mailing list >> thr...@li... >> https://lists.sourceforge.net/lists/listinfo/threeten-develop >> > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Stephen C. <sco...@jo...> - 2014-10-08 08:15:39
|
Just to note that if you create a DateTimeFormatterBuilder and use parseDefaulting() you can get this to work. http://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatterBuilder.html#parseDefaulting-java.time.temporal.TemporalField-long- The standard implementation will not make up a time out of thin air (it will default minutes, seconds and nanoseconds to zero, but not hours). Stephen On 8 October 2014 05:36, Roger Riggs <Rog...@or...> wrote: > Hi Ian, > > I think you answered your own question. If the pattern and the input > provide > only date information then only a LocalDate can be parsed. > > The nested exception says "Unable to obtain LocalTime from TemporalAccessor" > that indicates there is no time information in the input and so a LocalTime > cannot be created. Parsing can ignore extra information from the input > but cannot fabricate fields from no data. > > Regards, Roger > > > > On 10/7/14 6:56 PM, Ian Brandt wrote: > > Greetings, > > Feel free to direct me to another venue if this is the wrong place to post > this. I don’t have author status on the JDK Bug System, so I can’t file an > issue there. > > The new java.time API allows for the creation of a DateTimeFormatter pattern > that only includes a date portion; however, LocalDateTime fails to parse > such a pattern with a rather cryptic error: > > LocalDateTimeParseDateTest.java > ——— > import java.time.*; > import java.time.format.*; > import java.util.*; > > public class LocalDateTimeParseDateTest { > public static void main(String[] args) { > String dateString = "24-Aug-2009"; > DateTimeFormatter dateTimeFormatter = > DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US); > LocalDateTime.parse(dateString, dateTimeFormatter); > } > } > ——— > > $ java -version > java version "1.8.0_20" > Java(TM) SE Runtime Environment (build 1.8.0_20-b26) > Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) > > $ java LocalDateTimeParseDateTest > Exception in thread "main" java.time.format.DateTimeParseException: Text > '24-Aug-2009' could not be parsed: Unable to obtain LocalDateTime from > TemporalAccessor: {},ISO resolved to 2009-08-24 of type > java.time.format.Parsed > at > java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1918) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1853) > at java.time.LocalDateTime.parse(LocalDateTime.java:492) > at LocalDateTimeParseDateTest.main(LocalDateTimeParseDateTest.java:9) > Caused by: java.time.DateTimeException: Unable to obtain LocalDateTime from > TemporalAccessor: {},ISO resolved to 2009-08-24 of type > java.time.format.Parsed > at java.time.LocalDateTime.from(LocalDateTime.java:461) > at java.time.LocalDateTime$$Lambda$7/245257410.queryFrom(Unknown Source) > at java.time.format.Parsed.query(Parsed.java:226) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1849) > ... 2 more > Caused by: java.time.DateTimeException: Unable to obtain LocalTime from > TemporalAccessor: {},ISO resolved to 2009-08-24 of type > java.time.format.Parsed > at java.time.LocalTime.from(LocalTime.java:409) > at java.time.LocalDateTime.from(LocalDateTime.java:457) > ... 5 more > > > It works fine with “LocalDate.parse(dateString, dateTimeFormatter)”. I also > noticed it works for LocalDate with a pattern and input string that include > a time portion. To summarize: > > - LocalDate can use a DateTimeFormatter to parse even with a pattern that > includes a time portion. > - LocalDateTime cannot use a DateTimeFormatter to parse unless the pattern > includes a time portion. > > So a “narrowing conversion” from date-time to date works, but a “widening > conversion” from date to date-time does not. I’m sure it’s debatable, but > that seems a bit backwards to me. I believe a Joda DateTimeFormatter with a > date-only pattern successfully parses a Joda DateTime by just assuming > start-of-day for the time portion. I think it would be an improvement if > java.time followed suit. > > Best regards, > > Ian > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: Roger R. <Roger.Riggs@Oracle.com> - 2014-10-08 04:37:50
|
Hi Ian, I think you answered your own question. If the pattern and the input provide only date information then only a LocalDate can be parsed. The nested exception says "Unable to obtain LocalTime from TemporalAccessor" that indicates there is no time information in the input and so a LocalTime cannot be created. Parsing can ignore extra information from the input but cannot fabricate fields from no data. Regards, Roger On 10/7/14 6:56 PM, Ian Brandt wrote: > Greetings, > > Feel free to direct me to another venue if this is the wrong place to post this. I don’t have author status on the JDK Bug System, so I can’t file an issue there. > > The new java.time API allows for the creation of a DateTimeFormatter pattern that only includes a date portion; however, LocalDateTime fails to parse such a pattern with a rather cryptic error: > > LocalDateTimeParseDateTest.java > ——— > import java.time.*; > import java.time.format.*; > import java.util.*; > > public class LocalDateTimeParseDateTest { > public static void main(String[] args) { > String dateString = "24-Aug-2009"; > DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US); > LocalDateTime.parse(dateString, dateTimeFormatter); > } > } > ——— > > $ java -version > java version "1.8.0_20" > Java(TM) SE Runtime Environment (build 1.8.0_20-b26) > Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) > > $ java LocalDateTimeParseDateTest > Exception in thread "main" java.time.format.DateTimeParseException: Text '24-Aug-2009' could not be parsed: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO resolved to 2009-08-24 of type java.time.format.Parsed > at java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1918) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1853) > at java.time.LocalDateTime.parse(LocalDateTime.java:492) > at LocalDateTimeParseDateTest.main(LocalDateTimeParseDateTest.java:9) > Caused by: java.time.DateTimeException: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO resolved to 2009-08-24 of type java.time.format.Parsed > at java.time.LocalDateTime.from(LocalDateTime.java:461) > at java.time.LocalDateTime$$Lambda$7/245257410.queryFrom(Unknown Source) > at java.time.format.Parsed.query(Parsed.java:226) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1849) > ... 2 more > Caused by: java.time.DateTimeException: Unable to obtain LocalTime from TemporalAccessor: {},ISO resolved to 2009-08-24 of type java.time.format.Parsed > at java.time.LocalTime.from(LocalTime.java:409) > at java.time.LocalDateTime.from(LocalDateTime.java:457) > ... 5 more > > > It works fine with “LocalDate.parse(dateString, dateTimeFormatter)”. I also noticed it works for LocalDate with a pattern and input string that include a time portion. To summarize: > > - LocalDate can use a DateTimeFormatter to parse even with a pattern that includes a time portion. > - LocalDateTime cannot use a DateTimeFormatter to parse unless the pattern includes a time portion. > > So a “narrowing conversion” from date-time to date works, but a “widening conversion” from date to date-time does not. I’m sure it’s debatable, but that seems a bit backwards to me. I believe a Joda DateTimeFormatter with a date-only pattern successfully parses a Joda DateTime by just assuming start-of-day for the time portion. I think it would be an improvement if java.time followed suit. > > Best regards, > > Ian > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Ian B. <ia...@ia...> - 2014-10-08 02:22:52
|
Greetings, Feel free to direct me to another venue if this is the wrong place to post this. I don’t have author status on the JDK Bug System, so I can’t file an issue there. The new java.time API allows for the creation of a DateTimeFormatter pattern that only includes a date portion; however, LocalDateTime fails to parse such a pattern with a rather cryptic error: LocalDateTimeParseDateTest.java ——— import java.time.*; import java.time.format.*; import java.util.*; public class LocalDateTimeParseDateTest { public static void main(String[] args) { String dateString = "24-Aug-2009"; DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern("dd-MMM-yyyy", Locale.US); LocalDateTime.parse(dateString, dateTimeFormatter); } } ——— $ java -version java version "1.8.0_20" Java(TM) SE Runtime Environment (build 1.8.0_20-b26) Java HotSpot(TM) 64-Bit Server VM (build 25.20-b23, mixed mode) $ java LocalDateTimeParseDateTest Exception in thread "main" java.time.format.DateTimeParseException: Text '24-Aug-2009' could not be parsed: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO resolved to 2009-08-24 of type java.time.format.Parsed at java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1918) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1853) at java.time.LocalDateTime.parse(LocalDateTime.java:492) at LocalDateTimeParseDateTest.main(LocalDateTimeParseDateTest.java:9) Caused by: java.time.DateTimeException: Unable to obtain LocalDateTime from TemporalAccessor: {},ISO resolved to 2009-08-24 of type java.time.format.Parsed at java.time.LocalDateTime.from(LocalDateTime.java:461) at java.time.LocalDateTime$$Lambda$7/245257410.queryFrom(Unknown Source) at java.time.format.Parsed.query(Parsed.java:226) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1849) ... 2 more Caused by: java.time.DateTimeException: Unable to obtain LocalTime from TemporalAccessor: {},ISO resolved to 2009-08-24 of type java.time.format.Parsed at java.time.LocalTime.from(LocalTime.java:409) at java.time.LocalDateTime.from(LocalDateTime.java:457) ... 5 more It works fine with “LocalDate.parse(dateString, dateTimeFormatter)”. I also noticed it works for LocalDate with a pattern and input string that include a time portion. To summarize: - LocalDate can use a DateTimeFormatter to parse even with a pattern that includes a time portion. - LocalDateTime cannot use a DateTimeFormatter to parse unless the pattern includes a time portion. So a “narrowing conversion” from date-time to date works, but a “widening conversion” from date to date-time does not. I’m sure it’s debatable, but that seems a bit backwards to me. I believe a Joda DateTimeFormatter with a date-only pattern successfully parses a Joda DateTime by just assuming start-of-day for the time portion. I think it would be an improvement if java.time followed suit. Best regards, Ian |
From: Stephen C. <sco...@jo...> - 2014-03-05 10:10:45
|
Thanks to everyone on these lists who commented or contributed. And special thanks to Roger and Sherman for all their work. Enjoy JDK 8! Stephen On 4 March 2014 23:16, roger riggs <rog...@or...> wrote: > With the JCP Executive Committee finalizing the voting, > JSR 310 is approved and complete. > > The JSR 310 Date and Time API reference implementation is available. > > Many thanks and kudos to Stephen Colebourne and everyone who contributed to > JSR 310. > > Roger Riggs > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop > |
From: roger r. <rog...@or...> - 2014-03-04 23:16:32
|
With the JCP Executive Committee finalizing the voting <https://jcp.org/en/jsr/results?id=5639>, JSR 310 is approved and complete. The JSR 310 Date and Time API reference implementation <https://jdk8.java.net/java-se-8-ri/> is available. Many thanks and kudos to Stephen Colebourne and everyone who contributed to JSR 310. Roger Riggs |
From: roger r. <rog...@or...> - 2014-01-29 22:07:09
|
Hi, A few of issues in SE necessitated regenerating the JSR 310 RI and TCK (the same as the SE 8 RI and TCK). The JSR 310 Final Release Specification is unchanged. The RI binary is available from: https://jdk8.java.net/java-se-8-ri/ The updated TCK binaries are in the same directories on java-partner.sun.com. An update to the code coverage <http://cr.openjdk.java.net/%7Erriggs/jsr310-jcov.zip> [1] includes with more detail about individual packages and classes. The 93%, I reported is for the java.time package but the overall coverage number is lower (80%). The code/spec coverage can and should be improved over time. The submission to the PMO will be put off until next week to give it a bit of time to settle and final documentation be produced. fyi, Roger [1] http://cr.openjdk.java.net/~rriggs/jsr310-jcov.zip |
From: Stephen C. <sco...@jo...> - 2014-01-26 22:07:18
|
For those with the desire to read long standards documents, the Object Management Group (OMG) is defining a vocabulary/ontology for date and time: http://www.omg.org/spec/DTV/1.0/ Stephen |
From: Stephen C. <sco...@jo...> - 2014-01-23 16:18:49
|
On 23 January 2014 15:59, Douglas Surber <dou...@or...> wrote: > At 11:03 PM 1/22/2014, Stephen Colebourne wrote: >> >> > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? >> >> The java.lang.Integer class uses MAX_VALUE to return the equivalent >> primitive value. ie. Integer.MAX_VALUE returns an int not an Integer. >> With 310, there is no separate value type, so I used MAX. > > java.time.Year uses MAX_VALUE and MIN_VALUE. Because it returns int, not Year. > I think the distinction is too subtle for me. I would just type MAX_VALUE > because that is the name of the constant that defines the largest element in > the range, regardless of Object or primitive. I'm happy with the choice I made here. Its up to Roger/Sherman to comment otherwise. Stephen |
From: Douglas S. <dou...@or...> - 2014-01-23 15:59:51
|
At 11:03 PM 1/22/2014, Stephen Colebourne wrote: > > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used > elsewhere? > >The java.lang.Integer class uses MAX_VALUE to return the equivalent >primitive value. ie. Integer.MAX_VALUE returns an int not an >Integer. >With 310, there is no separate value type, so I used MAX. java.time.Year uses MAX_VALUE and MIN_VALUE. I think the distinction is too subtle for me. I would just type MAX_VALUE because that is the name of the constant that defines the largest element in the range, regardless of Object or primitive. Douglas |
From: Stephen C. <sco...@jo...> - 2014-01-23 07:03:41
|
On 22 January 2014 21:24, Douglas Surber <dou...@or...> wrote: > The JavaDoc for Instant.MAX says >>The maximum supported Instant, >>'1000000000-12-31T23:59:59.999999999Z'. > and for Instant.MIN says >>The minimum supported Instant, '-1000000000-01-01T00:00Z'. > This is +/- 1 * 10^9 years which conflicts with the Instant class > description which says: > >>The measurable time-line is restricted to the number of seconds that >>can be held in a long. This is greater than the current estimated >>age of the universe. The size of Instant was reduced to ensure that calculations returned correct numbers. This occurred when Instant was integrated with ZDT etc under the common Temporal interfaces. The two paragraphs above are now a spec error and should be removed. > Long.MAX_VALUE number of seconds is more than +/- 292 * 10^9 years > and the universe is 13.7 * 10^9 years old. > > Given the class description it seems incorrect that > > Instant.MAX.compareTo(Instant.ofEpochSeconds(Long.MAX_VALUE)) > returns -1. Instant.ofEpochSeconds(Long.MAX_VALUE) should throw an exception. Bug if it doesn't. > As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? The java.lang.Integer class uses MAX_VALUE to return the equivalent primitive value. ie. Integer.MAX_VALUE returns an int not an Integer. With 310, there is no separate value type, so I used MAX. Stephen > Douglas > > At 01:42 PM 1/17/2014, Roger Riggs wrote: >>Hi, >> >>Please review the >><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >>Release Specification (zip)[1] and materials. >> >>Updates to the specification since PFD: >> * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: >> java.time.Duration has wrong Javadoc Comments in toDays() and >> toHours() >> * The SE 8 javadoc has been used to generate the specification >> so its appearance is a bit different >> >>The code coverage is ~93% using jcov and is considered adequate. >> >>The RI and TCK are the same as for SE 8; since the development of >>the APIs >>and tests has been done via OpenJDK and earlier open source projects >>their contents are will known. >> >>The RI and TCK are being made available to official Expert Group >>members for review >>under a separate email. >> >>The FAB submission to the PMO is planned for 1/29. >> >>Please give your approval to proceed with the Final Release or raise >>any issues >>by Friday Jan 24th. >> >>Thanks, Roger >> >>[1] >><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip >> >>------------------------------------------------------------------------------ >>CenturyLink Cloud: The Leader in Enterprise Cloud Services. >>Learn Why More Businesses Are Choosing CenturyLink Cloud For >>Critical Workloads, Development Environments & Everything In >>Between. >>Get a Quote or Start a Free Trial Today. >>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk >> >>_______________________________________________ >>threeten-develop mailing list >>thr...@li... >>https://lists.sourceforge.net/lists/listinfo/threeten-develop > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: roger r. <rog...@or...> - 2014-01-22 22:55:22
|
Hi Douglas, I filed https://bugs.openjdk.java.net/browse/JDK-8032510 to keep track of this for a future version. Thanks, Roger On 1/22/2014 5:25 PM, Douglas Surber wrote: > Duration.dividedBy(Duration) is missing. This is needed to determine > the number of times a Duration occurs within another Duration, such > has how many 12 minute periods in 4 hours. Stephen agreed that this > was a good thing Jan 10, 2009. > > Douglas > |
From: Douglas S. <dou...@or...> - 2014-01-22 22:25:59
|
Duration.dividedBy(Duration) is missing. This is needed to determine the number of times a Duration occurs within another Duration, such has how many 12 minute periods in 4 hours. Stephen agreed that this was a good thing Jan 10, 2009. Douglas At 01:42 PM 1/17/2014, Roger Riggs wrote: >Hi, > >Please review the ><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >Release Specification (zip)[1] and materials. > >Updates to the specification since PFD: > * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: > java.time.Duration has wrong Javadoc Comments in toDays() and > toHours() > * The SE 8 javadoc has been used to generate the specification > so its appearance is a bit different > >The code coverage is ~93% using jcov and is considered adequate. > >The RI and TCK are the same as for SE 8; since the development of >the APIs >and tests has been done via OpenJDK and earlier open source projects >their contents are will known. > >The RI and TCK are being made available to official Expert Group >members for review >under a separate email. > >The FAB submission to the PMO is planned for 1/29. > >Please give your approval to proceed with the Final Release or raise >any issues >by Friday Jan 24th. > >Thanks, Roger > >[1] ><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip > >------------------------------------------------------------------------------ >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In >Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > >_______________________________________________ >threeten-develop mailing list >thr...@li... >https://lists.sourceforge.net/lists/listinfo/threeten-develop |
From: Douglas S. <dou...@or...> - 2014-01-22 21:25:02
|
The JavaDoc for Instant.MAX says >The maximum supported Instant, >'1000000000-12-31T23:59:59.999999999Z'. and for Instant.MIN says >The minimum supported Instant, '-1000000000-01-01T00:00Z'. This is +/- 1 * 10^9 years which conflicts with the Instant class description which says: >The measurable time-line is restricted to the number of seconds that >can be held in a long. This is greater than the current estimated >age of the universe. Long.MAX_VALUE number of seconds is more than +/- 292 * 10^9 years and the universe is 13.7 * 10^9 years old. Given the class description it seems incorrect that Instant.MAX.compareTo(Instant.ofEpochSeconds(Long.MAX_VALUE)) returns -1. As an aside, why 'MAX' rather than 'MAX_VALUE' as is used elsewhere? Douglas At 01:42 PM 1/17/2014, Roger Riggs wrote: >Hi, > >Please review the ><http://cr.openjdk.java.net/%7Erriggs/datetime-1_0-fr-spec.zip>Final >Release Specification (zip)[1] and materials. > >Updates to the specification since PFD: > * <https://bugs.openjdk.java.net/browse/JDK-8031103>8031103: > java.time.Duration has wrong Javadoc Comments in toDays() and > toHours() > * The SE 8 javadoc has been used to generate the specification > so its appearance is a bit different > >The code coverage is ~93% using jcov and is considered adequate. > >The RI and TCK are the same as for SE 8; since the development of >the APIs >and tests has been done via OpenJDK and earlier open source projects >their contents are will known. > >The RI and TCK are being made available to official Expert Group >members for review >under a separate email. > >The FAB submission to the PMO is planned for 1/29. > >Please give your approval to proceed with the Final Release or raise >any issues >by Friday Jan 24th. > >Thanks, Roger > >[1] ><http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip>http://cr.openjdk.java.net/~rriggs/datetime-1_0-fr-spec.zip > >------------------------------------------------------------------------------ >CenturyLink Cloud: The Leader in Enterprise Cloud Services. >Learn Why More Businesses Are Choosing CenturyLink Cloud For >Critical Workloads, Development Environments & Everything In >Between. >Get a Quote or Start a Free Trial Today. >http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > >_______________________________________________ >threeten-develop mailing list >thr...@li... >https://lists.sourceforge.net/lists/listinfo/threeten-develop |