parse is less permissive than before

[teawaterwire]

Maybe this has been done on purpose, but here's something I could do with 0.4.0:

(tf/parse (tf/formatter "YYYY") "201712")
;; #object[Object 1483228800000]

Trying with later versions (ex. with latest) I get the following:

(tf/parse (tf/formatter "YYYY") "201712")
;; Invalid format: 201712 is malformed at ("1" "2")

Is there a way to modify the current parse function (below) to be a bit more permissive? https://github.com/andrewmcveigh/cljs-time/blob/ea76ee787353762088892912f8c17863316e9f6d/src/cljs_time/internal/parse.cljs#L278-L292

[andrewmcveigh]

Hi,

Although this wasn't done on purpose, I'm not sure I want to make this "more permissive".

The problem with that is defining what more permissive means. Should we parse: (tf/parse (tf/formatter "YYYY") "201712") as a date with the year 2017, and throw away the 12 part as the month? Or should we parse the year as 201712?

It might sound a bit silly to ask that question, but what about (tf/parse (tf/formatter "YYYY") "10000")?

clj-time by the way:

(parse (formatter "YYYY") "201712")
#object[org.joda.time.DateTime 0x18a7256d "201712-01-01T00:00:00.000Z"]

As I don't want to intentionally break API compatibility with clj-time, and there is already some meaning in 4-letter parse/formatters, I'd lean towards "fixing" this by matching their behaviour.

But, I don't think that's what you mean by "more permissive".

Maybe, being more permissive is better handled in user code, where you can explicitly say how to handle this ambiguity?

[teawaterwire]

Hi,

I actually didn't think about the year 201712 – it was too far away from me 😄 – but that really drives the point home. Thanks!

I guess it'd make sense to match clj-time behaviour indeed.

It feels now that handling the ambiguity in user code might be overkill when in the end I just need to subs the input string 👌

[danielcompton]

I think this can be closed now, but feel free to reopen if there is more to discuss here. Thanks!