Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency in parsing data with local-date #11

Open
elisehuard opened this issue Aug 16, 2017 · 2 comments
Open

Inconsistency in parsing data with local-date #11

elisehuard opened this issue Aug 16, 2017 · 2 comments

Comments

@elisehuard
Copy link

I want to process a timeseries with monthly labels, so something like "2012-10" etc, but parser seems unhappy with this. I understand why, but it's pretty impractical.

user> (local-date-time "MM/yyyy" "09/2015")                                                       
DateTimeException Unable to obtain LocalDate from TemporalAccessor: {MonthOfYear=9, Year=2015},IS\
O of type java.time.format.Parsed  java.time.LocalDate.from (LocalDate.java:368)                  
user> (local-date 2015 10)                                                                        
#object[java.time.LocalDate 0x6a08b281 "2015-10-01"
@dm3
Copy link
Owner

dm3 commented Aug 16, 2017

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)))

@dm3
Copy link
Owner

dm3 commented Aug 18, 2017

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants