DEV Community

Discussion on: Oh Javascript... 🙄

Collapse
 
squgeim profile image
Shreya Dahal

The thing is initializing dates with string is very ambiguous and depends heavily on what browser you are using. The only format with any guarantee is IOS 8601.

I have a more detailed write up on this, with a lot more caveats: blog.lftechnology.com/date-ing-jav...

Collapse
 
kspeakman profile image
Kasey Speakman

Problem is that ISO 8601 does not work well for dates. If I save to local storage in that format, then the user closes their laptop and hops on an airplane going from London (UTC+1) to New York (UTC-4 currently). When they arrive and open the app again, I reload the ISO dates from local storage they will all be off by one day. This leads me to one of two conclusions. Abandon JS Date. OR The only safe way to initialize a date in local time across browsers is using the integer-based constructor with that 0-based month nonsense.

Collapse
 
squgeim profile image
Shreya Dahal

That is true. This was a major issue for us in the backend, because even if we stored a date value in the database as just date, it would come to javascript as a date object, and go to the frontend as ISO 8601 string.

We had to configure the postgres driver for node to not automatically parse dates and make sure we only initialize dates in the frontend with number arguments.