JavaScript's Date Object Delivers Another Round of Parsing Surprises
Description
A screenshot of a Twitter thread discussing the notoriously quirky and inconsistent behavior of JavaScript's `Date` object constructor. The initial tweet by Christina Holland shows a code snippet where `new Date(0)` correctly returns the Unix epoch start time (Dec 31, 1969, in a GMT-0800 timezone), but `new Date('0')` unexpectedly returns January 1, 2000. This is because the constructor's string parsing behavior is highly implementation-dependent and often leads to non-intuitive results. A reply from Thomas Shaddox adds another example, showing that `new Date('2020-01-01')` is parsed as UTC, resulting in a date in the previous year for the local timezone, while `new Date('2020/01/01')` is parsed correctly as local time. This meme is deeply relatable to any developer who has struggled with date and time manipulation in JavaScript, a classic pain point that has led to the widespread adoption of libraries like Moment.js or date-fns
Comments
43Comment deleted
The JavaScript Date constructor is the ultimate legacy system: it's been broken in weirdly specific ways for so long that all the bizarre behavior is now considered part of the spec
JavaScript’s Date constructor: where int 0 means 1969, string “0” means Y2K, and “2020-01-01” means 2019 - because nothing says ‘web standard’ like three decades of history encoded in one ambiguous overload
After 20 years in the industry, I've learned that JavaScript's Date constructor isn't broken - it's just teaching us that time is relative, formats are suggestions, and the only consistent thing about dates is that they'll consistently surprise you in production at 3 AM
Ah yes, JavaScript's Date constructor - where passing 0 gives you 1969 (Unix epoch), passing '0' gives you Y2K, and the difference between '2020-01-01' and '2020/01/01' is whether you want your dates served with a side of timezone confusion. It's the API equivalent of a restaurant where ordering 'steak' gets you chicken, ordering '"steak"' gets you fish, and the format of your reservation determines which kitchen prepares it. No wonder the TC39 committee is building Temporal - Date() has been gaslighting developers since Netscape Navigator
JS Date('2019-01-01'): because nothing says 'Happy New Year' like teleporting to 2018 in PST
Hyphens parse as UTC, slashes as local - if your ETL partitions use new Date(string), congratulations: you’ve implemented accidental time-travel and a quarterly restatement
JavaScript Date: '-' is ISO/UTC, '/' is legacy locale, and '0' hits the Y2K two‑digit‑year pivot and lands in 2000 - aka Surprise Standard Time
This all very well may be in full accordance with the specification but really, the specification that allows this is very much fcked up. Comment deleted
No way this shit can be included in specification. This is one of the "you are not supposed to" ways of using parameters Comment deleted
Skill issues Comment deleted
2020-01-01 is treated as Date time string format (pretty much ISO 8601) and being restored as 2020-01-01T00:00:00.000+00:00 , which gives us UTC timezone, whereas 2020/01/01 is a subject for some uugh-we-gotta-support-this-shit-implemented-parsing that doesn't affect the timezone (and, imho, it's much more useful this way). Now, new Date('0') is a real nightmare, because it's an uugh-we-gotta-support-this-shit-implemented-parsing that decides that 0 means 0'th year (which's 2000), but if we make it new Date('1'), then boom! - it's 1-1-1 in US notation (m/d/y). As well as new Date('3') is 3-1-1 = 3/1/2001. Comment deleted
So basically US date formats are fucked up in any language. 😇 Comment deleted
More like US date format fucks up any date format that's "not clear enough" in implementer's opinion Comment deleted
Kill it with fire Comment deleted
thank god for datefns Comment deleted
I’m using Day.js instead Comment deleted
Avoid creating dates using strings without explicit in-place format specification. If you create from string always specify format Comment deleted
In any language! Comment deleted
I remember JS Date month start index from 1...right? Comment deleted
JS should come up with a new set of primitives that are implemented without those shitty legacy 'uhh we gotta support this garbage' edge cases and then we can all start pretending all that old shit does not exist, same way we pretend node.js style callbacks never happened Comment deleted
or whatever the fuck we were doing before querySelectorAll became a thing Comment deleted
The language should be backwards-compatible. It's amazing tho how many slow and idiotic decisions might have been thrown off from, for example, jQuery, if they'd just dropped old browser support (like really old, e.g. IE 9 and below). I guess, the only reason for not implementing some brand new Date class (with different name ofc) is that people would still have to code all the backwards compatibility mumbo-jumbo with current Date class - for old browser support, for another 15+ years. While, at the same time, there's Luxon which a lot of people use anyway. Comment deleted
I'm not saying it shouldn't be backwards compatible but there's a reason why most JS developers have no idea what document.write is and how it works, even if it still does Comment deleted
Let alone JS, HTML and CSS are rarely used to now. Just slap a design in figma and extract it as jsx, lol. What you really have to know about js is not how to deal with types. More than half of what you need to understand are events and requestAnimationFrame Comment deleted
not sure if trolling or just dumb so /thread for me lol Comment deleted
plain html with a small amount of css and maybe js (only if it's absolutely necessary) is all you need Comment deleted
Fuck CSS, I still sometimes try using table to align elements Comment deleted
why not flexbox/grid? Comment deleted
I hate CSS as a whole, bcuz the end result is always ambiguous. All those em, %, vh, make me use js getComputedStyle method on element to find out wtf is its actual size Comment deleted
wtf are you trying to do Comment deleted
Adaptive carousel with scroll snapping Comment deleted
people would still have to code all the backwards compatibility mumbo-jumbo with current Date class everyone (except DHH lol) uses transpilers these days so that's a non-issue, just slap a polyfill on top and wait 2-3 years Comment deleted
So, generally, it's MS who should add a new Date class, not ECMA, right? 🌚 Comment deleted
it's 2024, you mean Google 😁 Comment deleted
I think MooTools should do that, last time they've added .flatten on Array.prototype we almost ended up with .smoosh in the standard lib 🤡 they clearly know how to force everyone to support them 😂 Comment deleted
While, at the same time, there's Luxon which a lot of people use anyway. I mean, Luxon runs on Intl so it already uses "the new APIs" (which is a problem in JS environments where Intl is poorly supported, e.g. JSC/Hermes) Comment deleted
To add to this, everything is documented. Don't fuck around with passing vague types to methods, pass unix timestamp as an int or supply a date in a standard ISO format as a string. Have a fucky date format like in the US? Normalize it to ISO first. Want to *get* a fucky format for display? Intl class has you covered. Especially with dates, you have to be very specific. Hell is date "0"? 1970? Birth of Jesus? In what timezone? Comment deleted
Soon we will reinvent babel Comment deleted
or document.write, or a dozen other shitty APIs that are still lingering but we have better alternatives Comment deleted
It is a JS problem... it shouldnt try to cast to 90 different types to make sense of the content in any way possible. It should fail and throw an exception. Comment deleted
https://tc39.es/proposal-temporal/docs/ Comment deleted
Learn English please Comment deleted
I wish CSS perishes one day, the worst thing in web Comment deleted