28 and 2025-05-28 different days in JavaScript?

62 points by runxiyu

jdheyburn

The last quip was a TIL for me. I had a play around in dev tools and looks like whatever the last appearing month “wins” the parse.

adamshaylor

This is a good reason to stick to ISO-8601 when producing and consuming date strings in a JavaScript context, and also to use a timezone designator unless you literally mean whatever the local time is wherever the user happens to be.

Halkcyon

RFC3339 would be my preference, for any date/time communications, in any language (including English writing). Naive datetimes are not useful in most cases unless you’re discussing recurring events in a local time.
- masklinn
  
  I don’t think many people understand the nuance of the -00:00 offset so I’d dispute its usage in any langage at all.
  
  And more problematically neither copes well with future events, for that you need RFC 9557
  - adamshaylor
    
    What I see a lot of is data that’s not in any explicit format—data that happens to work with whatever language parser (like the slash format as parsed by JS’ Date() constructor in this article) or library (e.g. moment.js’ proprietary format) the author happened to be using at the time. I also see databases that use ISO 8601 without timezone designators working under the false assumption that all clients will interpret it as UTC. It’s all well and good to speak of the superiority of RFC 9557, which will be nice once the Temporal API is broadly supported, but until then, I would consider getting people just to use ISO 8601 with timezone designators a major improvement over the status quo.
    
    snej
    
    When I worked on an RSS reader, 20 years ago(!), we parsed dates by iterating a list of about a dozen format strings, until one of them worked. People put the craziest shit in their feeds and if we didn’t handle it, we got bug reports.
  - whostolemyhat
    
    Easy enough to miss in the UK since they end up as the same date, but with different times
    
    new Date('2025/05/28') // midnight Wed May 28 2025 00:00:00 GMT+0100 (British Summer Time) new Date('2025-05-28') // 1am Wed May 28 2025 01:00:00 GMT+0100 (British Summer Time)
    
    I’ve run into this a bit at work recently where some teams are storing dates as datetimes, which end up being converted into the wrong date when we fetch them into the UI. Temporal can’t arrive soon enough!