Inconsistency in parsing data with local-date #11

Activity

1. dm3 commented on Aug 16, 2017

   

   dm3

   on Aug 16, 2017

   Owner

   More actions

   Sadly, this library doesn't do much outside of what is provided by the java.time API. This is the limitation of the DateTimeFormatter:

   boot.user=> (java.time.LocalDate/parse "2017/05" (java.time.format.DateTimeFormatter/ofPattern "yyyy/MM"))
   
               java.time.DateTimeException: Unable to obtain LocalDate from TemporalAccessor: {Year=2017, MonthOfYear=5},ISO of type java.time.format.Parsed
   java.time.format.DateTimeParseException: Text '2017/05' could not be parsed: Unable to obtain LocalDate from TemporalAccessor: {Year=2017, MonthOfYear=5},ISO of type java.time.format.Parsed
   

   I can only recommend something like:

   (defn month-year->local-date-time [^String str]
     (->> (.split str "\\/") (map #(Integer/parseInt %)) (reverse) (apply j/local-date-time)))

   👍React with 👍1Reacted by Elise Huard
2. dm3 commented on Aug 18, 2017

   

   dm3

   on Aug 18, 2017

   Owner

   More actions

   I can imagine a feature that would harmonize the Number* -> TemporalEntity constructors with their parse counterparts. It should require a dynamic context set up before parsing, or a special kind of formatter used so that the default (strict) behaviour is preserved.

   There's a DateTimeFormatter#parseUnresolved which can be used to obtain a parsed TemporalAccessor which then needs to be resolved manually. However, there doesn't seem to be an easy way to just throw more default fields into the parse result and resolve it.

   If anyone wants to tackle this - I'd be happy to collaborate :)
3. dm3

   added

   enhancement

   on Aug 18, 2017