Date.fromString should not rely on new Date(...)

[Zimmi48]

Hello,
The following SSCCE shows an unexpected result 2011 when we should instead display Error:

import Date
import Html


main =
  Date.fromString "14/01/2010"
  |> Result.map (Date.year >> toString)
  |> Result.withDefault "Error"
  |> Html.text

(tried in elm-lang.org/try in Firefox)

This problem does not arise in elm repl:

> import Date
> Date.fromString "14/01/2010" |> Result.map (Date.year >> toString) |> Result.withDefault "Error"
"Error" : String

[halfzebra]

Date constructor in JavaScript offers consistent parsing behavior only for ISO 8601 formatted date strings.

You have happened to use an invalid ISO 8601 date string, which leads to that error.

Maybe it would make sense to add some validation mechanism to Native.Date.fromString to ensure, that Date constructor will only get a valid ISO 8601 formatted date.

E.g. JavaScript implementation of http://www.pelagodesign.com/blog/2009/05/20/iso-8601-date-validation-that-doesnt-suck/

[halfzebra]

Date constructor in JavaScript offers consistent parsing behavior only for ISO 8601 formatted date strings.

You have happened to use an invalid ISO 8601 date string, which leads to that error.

Maybe it would make sense to add some validation mechanism to Native.Date.fromString to ensure, that Date constructor will only get a valid ISO 8601 formatted date.

E.g. JavaScript implementation of http://www.pelagodesign.com/blog/2009/05/20/iso-8601-date-validation-that-doesnt-suck/

[Zimmi48]

@halfzebra Thanks for the feedback.
I get what you mean and yes, I think it would make sense to add a validation mechanism, or even better, re-implement the function in pure Elm: a well-behaved language such as Elm shouldn't rely on inconsistent implementations in JS. If a function behaves in some way in the repl, it should behave in the same way in the browser.

[Zimmi48]

@halfzebra Thanks for the feedback.
I get what you mean and yes, I think it would make sense to add a validation mechanism, or even better, re-implement the function in pure Elm: a well-behaved language such as Elm shouldn't rely on inconsistent implementations in JS. If a function behaves in some way in the repl, it should behave in the same way in the browser.

[Zimmi48]

To confirm that this is a problem imported from JS: on Chromium, the same program displays Error

[Zimmi48]

To confirm that this is a problem imported from JS: on Chromium, the same program displays Error

[avh4]

If someone can implement validation or pure-elm parsing and merge it to rluiten/elm-date-extra or another published package, that would be a good start.

[avh4]

If someone can implement validation or pure-elm parsing and merge it to rluiten/elm-date-extra or another published package, that would be a good start.

[mariosangiorgio]

Hello, is there any update on this issue? I just got confused by the formats used by Date.fromString and opened #701 (sorry for the duplicate)

[mariosangiorgio]

Hello, is there any update on this issue? I just got confused by the formats used by Date.fromString and opened #701 (sorry for the duplicate)

[halfzebra]

Date.Extra.fromIsoString is capable of parsing ISO 8601 date strings, without causing run-time errors.

I do agree with everything, from #701, Date.fromString should have some extra validation.

[halfzebra]

Date.Extra.fromIsoString is capable of parsing ISO 8601 date strings, without causing run-time errors.

I do agree with everything, from #701, Date.fromString should have some extra validation.

[daniellandau]

I just ran into a problem with this in production. My situation is that I rely on Date.fromString to fail on invalid input so that Json.oneOf tries the next decoder in the list. In Firefox this works perfectly, but Chrome/Chromium happily give a nonsensical but valid date with for example new Date("3")

[daniellandau]

I just ran into a problem with this in production. My situation is that I rely on Date.fromString to fail on invalid input so that Json.oneOf tries the next decoder in the list. In Firefox this works perfectly, but Chrome/Chromium happily give a nonsensical but valid date with for example new Date("3")

[halfzebra]

@daniellandau for now you can use Json.Decode.andThen to parse a string firs and then do Date.Extra.fromIsoString to parse it properly.

[halfzebra]

@daniellandau for now you can use Json.Decode.andThen to parse a string firs and then do Date.Extra.fromIsoString to parse it properly.

[lukewestby]

Tracking in #816

[lukewestby]

Tracking in #816