Re: [threeten-develop] LocalDateTime fails to parse date-only pattern

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

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