Wow, it is much worse than I thought! I think it is fair to categorize this in "the truly awful parts" of Javascript.
For the most part, I avoid working with dates in JS. In client-server apps I deal with them on the server and send dates back only as display strings for the client where possible. But in this case, I am doing a client-side-only app which needs to process dates and schedules. So I have to try to use the "least bad parts". I'm half-tempted to port moment.js or NodaTime to Elm.
Using moment does not solve this issue. Initializing date with a string that is not strictly ISO 8601 is inconsistent in the specification itself and depends on the browser.
On Safari:
> new Date('2018-3-14')
â‹– Invalid Date
> moment('2018-3-14')
â‹– Invalid Date
Wow, it is much worse than I thought! I think it is fair to categorize this in "the truly awful parts" of Javascript.
For the most part, I avoid working with dates in JS. In client-server apps I deal with them on the server and send dates back only as display strings for the client where possible. But in this case, I am doing a client-side-only app which needs to process dates and schedules. So I have to try to use the "least bad parts". I'm half-tempted to port moment.js or NodaTime to Elm.
At my company, we use moment.js. My colleagues recommend that.
Using moment does not solve this issue. Initializing date with a string that is not strictly ISO 8601 is inconsistent in the specification itself and depends on the browser.
On Safari:
This works on Chrome, though. :D
More about the moment issue here: github.com/moment/moment/issues/1407
I have a more thorough write-up on this with a lot more caveats here: blog.lftechnology.com/date-ing-jav...
Thanks for the link. That is a great article on many of the JS Date caveats.