It's a fun quiz, and there's a lot of surprising behaviour. However in my opinion from a practical perspective it mostly doesn't matter.
Think hard about whether your use case really cares about local time, try and find ways to make instants appropriate. Then stick to UTC ISO 8601 strings / Unix timestamps and most of the complexity goes away, or at least gets contained to a small part of your software.
I know this isn't always possible (I once had to support a feature that required the user took a break covering two periods of 1-5am local, which was obviously fun around DST boundaries) - but in my experience at least the majority of the time you can find ways to minimise the surface area that cares.
If you're passing raw/unvalidated user input to the date parser you're holding it wrong.
Hilift
I agree, and/or give an option to specify the DST offset. That is sometimes useful. I was always confused that Excel did not infer the format when using CSV's though.
JonChesterfield
Given that the right way to turn user input into validated input is to _parse_ it, passing it to the language feature called the _date parser_ is a completely reasonable thing to do. That this doesn't work probably doesn't surprise javascript programmers much.
mnahkies
Yeah this is a fair take - I guess my unwritten stipulation was don't expect anything from the JavaScript standard library to behave as you'd expect, outside of fairly narrow paths.
TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.
lukan
"If you're passing raw/unvalidated user input to the date parser you're holding it wrong."
Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.
samwho
I agree with this. I do think it’s an easy trap to fall into if you’re unfamiliar, and hopefully this quiz has made a whole wave of folks more familiar. :)
schoen
Lots of surprises here! The general theme seems to be that the parser is very eager to find some interpretation of the input as a date, even in ways that appear pretty unprincipled, even in circumstances where human users would probably not agree with the interpretation, and even though it does have ways that it could signal errors. Though maybe some of the weird cases actually do trace back to unusual real-world use cases!
I'm not sure if I should be pleased or embarrassed about my 17/28. Why do I even know this?
My son was pretty happy with his 11/28 without any experience with js Date. Just deduced it from previous answers. And I explained type coercion to him.
I now realize I may have put him off a career in IT.
samwho
It very much is. I put the lil notice at the start that I verified the questions on a specific version of Node, with a specific timezone, because both things matter.
zinekeller
Some notes that I have noticed. First, why does it seem that the V8 date parser is heavily inspired by the Windows date parser (https://devblogs.microsoft.com/oldnewthing/20200304-00/?p=10...)? EDIT: Apparently not, "new Date('Savvyday 29 Oatmeal 94')" is invalid both in Firefox and Chrome.
Second, I opened this in Firefox with the console open to answer these questions, and found these divergences (to summarize, Firefox is strict):
Question 14:
new Date("12.1")
> "12.1" is interpreted as the date December 1st, and as before for dates with no year the default is 2001 because of course.
Firefox returns an Invalid Date object instead.
Question 16:
new Date("12.-1")
> The dash here is ignored, so this is interpreted the same as "12.1".
Again, Firefox returns an Invalid Date object instead.
Question 19:
new Date("maybe 1")
> "may" in "maybe" is parsed as the month May! And for some reason this expression cares about your local timezone, which happens to be BST for me right now.
Seems a broken record, but this is still an Invalid Date for Firefox.
Question 20:
new Date("fourth of may 2010")
> "fourth of" is ignored, this is just parsing "may 2010" and again local timezone is important.
Ibid in Firefox.
Question 21:
new Date("May 4 UTC")
> UTC is correctly parsed as a timezone.
No, Firefox is still not accepting this one.
Question 22:
new Date("May 4 UTC+1")
> You can add modifiers to timezones and it works as you would expect.
Neither this one.
Question 23:
new Date("May 4 UTC+1:59")
> It also supports minutes!
Firefox: Not really.
Final note: It parses Question 24 as you expect in Firefox. Which honestly, it shouldn't!
mnahkies
It's probably improved the past 8 years or so, but I remember Safari was particularly bad for bugs around DST and just dates in general back then, even when using valid input.
We ended up with a bunch of Safari specific workarounds that weren't necessary on Chrome (it was mostly a webview use case so Safari and Chrome were the two we cared about at the time)
A quick test of Vivaldi with some of those shows it nowhere near as strict as your Firefox is. Amusingly
new Date("2025-07-12 12:30:45 BST")
is an invalid date, whereas all three of
new Date("2025-07-12 12:30:45 GMT")
new Date("2025-07-12 12:30:45 UTC")
new Date("2025-07-12 12:30:45 Z")
are valid but in British Summer Time.
samwho
Yeah, as I understand it this isn’t backed by any spec. I decided to go with Node’s (v8’s) implementation for the quiz. Fun to see how much divergence there is!
12/28, could've gotten a few more by thinking harder, but I was getting so annoyed that I didn't want to, great job!
tialaramex
In a language which doesn't understand that "false" isn't true? I would be entirely unsurprised to discover it's secretly calling a browser vendor web API to search for similarly named dates, or that it's now AI powered and might decide "Last Christmas" means the release date (December 3 1984) of the single not like, Christmas Day in 2024...
I think after the 1970s "Worse is better" languages vanish from the Earth the last shadow of that thinking left might be Javascript, hopefully by then humans aren't writing it but of course for "compatibility" it'll still be implemented by web browsers.
wiseowise
Why wouldn’t “false” be true? It’s a non-empty string.
tialaramex
For the same reason dogs aren't the square root of two and justice isn't golf? They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.
wiseowise
You've completely disregarded type system rules of the language, and continue doubling down on your ignorance with ridiculous examples.
> They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.
You don‘t think being able to check the truthiness of strings is a useful thing?
camblomquist
Because "0" is false. In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
wiseowise
```
> if ("0") console.log("true");
true
```
Excuse me?
> In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
You must hate our illogical world built on C, because it has the same behavior.
camblomquist
I did a `"0" == false` which returned true. I may need another cup of coffee before making claims.
ascar
yea that's an odd example to pick. expecting type conversion to add meaning to strings is a programmer problem not a language problem. really comes down to developers not thinking about types and their meaning anymore.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
010101010101
It’s the _existence_ of an implicit conversion from string to boolean that the parent is pointing out as a problem, not how it’s implemented. But that’s Jãvascript bb
echoangle
Maybe I’m missing the example but can you not check the truthiness of strings in basically any high level language? At least python does it the same way and it’s very useful.
bapak
Are you crazy? Which language does? I can only think of markup languages that do.
Should "0" also === 0? How about "{}" === {}? When does it stop?
nailer
What do you mean? false isn’t true in JavaScript.
Filligree
“false”, not false. So there’s odd type coercion, but the problem is that it can happen without you asking for it.
Python does the same thing. I don’t like it there either, but at least it’s more consistent about it.
nailer
Yes strings aren’t false unless they’re empty. Good thing.
astura
The string with the value of "false" evaluates to true.
In other words
If ("false") {
/* You will be here */
}
torlok
Always fun to click through JS quizzes for the laughs. I've been programming JS since over a decade, and I never dared to use Date to parse anything I didn't verify with a regex.
worble
So... any browser other than Firefox feel like shipping Temporal yet?
I'm not sure if it's caused by JavaScript quirkiness under the hood or a bug in the library, but it's mindblowing.
wiseowise
Cute. But things like these have tendency to be abused by “haha, js” crowd even if those things are irrelevant in practice.
rplnt
Generally true, but the Date and everything around it being absolutely incomprehensible and totally bonkers is very relevant in practice. It's pain to use and triggers billions of bugs daily. It's not an abuse to point out even more wtf about it.
samwho
This matches my experience. This is a bit of fun but I’m hoping it has the positive side effect of making people more cautious about how they use Date.
AndroTux
date.getYear() => 125
If that’s not relevant, I don’t know what is.
wiseowise
> date.getFullYear() => 2025
`getYear` is literally deprecated everywhere and is not part of the spec.
Since the website says "All questions verified using NodeJS 24.4.0" and that all string parsing made by the Date constructor is define in ECMAScript to follow ISO 8601 plus being engine specific, the sub headline should say: How well do you know V8's Date parsing?
bagol
I'm curious how would a formal spec define those behaviors.
kevincox
IIRC it was basically undefined, some data formats were defined. Eventually it was specified that it must correctly parse RFC 3339 and everything was browser defined. I think in the name of web compatibility they have started to carefully define the legacy behaviours of common browsers.
But the morale of this story should be if you need a date from a user user a date input and if you need to parse a computer-readable date always use UNIX timestamps or RFC 3339 (which are correctly and consistently supported).
I just fixed a bug at work where JS Date was parsing arbitrarily long strings as random date values just because they happened to contain an integer anywhere in the string. Madness.
ilovethe80s
JavaScript has survived because it must be backwards compatible, not because it ever made sense.
Adding Temporal will only add to the chaos. Now there will be Date, moment, Luxon’s objects, and Temporal. See??? We fixed it!!!
actinium226
Temporal is the language's attempt to fix the issues, instead of relying on 3rd party tools. The current situation forces developers to either choose something supported by the language, which has certain guarantees for backwards compatibility but is awful, and a 3rd party tool, which does not and is not as bad. It seems like the logical resolution is for the language to step up its game, since 3rd party tools have no obligation to be maintained or backwards compatible, or even to remain popular.
mcv
Too many standards? Time to add another one. This one will be final, I promise.
bubblebeard
Haha that was fun :D
Thanks!
croes
Why?
samwho
I discovered the 0/“0” disparity in work this week for the first time. Then I tried “1” and “2” and knew there was fun to be had. :)
Think hard about whether your use case really cares about local time, try and find ways to make instants appropriate. Then stick to UTC ISO 8601 strings / Unix timestamps and most of the complexity goes away, or at least gets contained to a small part of your software.
I know this isn't always possible (I once had to support a feature that required the user took a break covering two periods of 1-5am local, which was obviously fun around DST boundaries) - but in my experience at least the majority of the time you can find ways to minimise the surface area that cares.
If you're passing raw/unvalidated user input to the date parser you're holding it wrong.
TBH even when working with other languages I'd skew towards doing this, possibly because I've worked with JavaScript/TypeScript too much. It's a balance but there's a certain comfort in making constraints really explicit in code you control over blindly trusting the standard library to keep it's behaviour over the lifetime of the product.
Exactly. I would have never thought about using the Date class in this way. So the behavior is pretty much wtf and local time can get pretty complicated, but I wouldn't expect to get the right time, when passing some vague strings.
My son was pretty happy with his 11/28 without any experience with js Date. Just deduced it from previous answers. And I explained type coercion to him.
I now realize I may have put him off a career in IT.
Second, I opened this in Firefox with the console open to answer these questions, and found these divergences (to summarize, Firefox is strict):
Question 14:
> "12.1" is interpreted as the date December 1st, and as before for dates with no year the default is 2001 because of course.Firefox returns an Invalid Date object instead.
Question 16:
> The dash here is ignored, so this is interpreted the same as "12.1".Again, Firefox returns an Invalid Date object instead.
Question 19:
> "may" in "maybe" is parsed as the month May! And for some reason this expression cares about your local timezone, which happens to be BST for me right now.Seems a broken record, but this is still an Invalid Date for Firefox.
Question 20:
> "fourth of" is ignored, this is just parsing "may 2010" and again local timezone is important.Ibid in Firefox.
Question 21:
> UTC is correctly parsed as a timezone.No, Firefox is still not accepting this one.
Question 22:
> You can add modifiers to timezones and it works as you would expect.Neither this one.
Question 23:
> It also supports minutes!Firefox: Not really.
Final note: It parses Question 24 as you expect in Firefox. Which honestly, it shouldn't!
We ended up with a bunch of Safari specific workarounds that weren't necessary on Chrome (it was mostly a webview use case so Safari and Chrome were the two we cared about at the time)
Assumingly to me this was around the same time that Apple seemed to have DST problems more generally, such as their iOS alarm clock mishap https://www.theguardian.com/technology/blog/2010/nov/01/ipho...
I think after the 1970s "Worse is better" languages vanish from the Earth the last shadow of that thinking left might be Javascript, hopefully by then humans aren't writing it but of course for "compatibility" it'll still be implemented by web browsers.
> They're not the same kind of thing at all, if you insist that we should be able to compare them then they're not equal, and since programmers are human and make mistakes probably comparing them is itself a mistake.
It is literally encoded in the spec.
https://262.ecma-international.org/13.0/#sec-toboolean
true ```
Excuse me?
> In a logical world, a non-empty string being truthy is fine even if the value is "false". Javascript isn't logical.
You must hate our illogical world built on C, because it has the same behavior.
there are plenty of javascript examples that are actually weird though, especiall when javascript DOES apply meaning to strings, e.g. when attempting implicit integer parsing.
Should "0" also === 0? How about "{}" === {}? When does it stop?
Python does the same thing. I don’t like it there either, but at least it’s more consistent about it.
In other words
If ("false") { /* You will be here */ }
I'm not sure if it's caused by JavaScript quirkiness under the hood or a bug in the library, but it's mindblowing.
If that’s not relevant, I don’t know what is.
`getYear` is literally deprecated everywhere and is not part of the spec.
https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
But the morale of this story should be if you need a date from a user user a date input and if you need to parse a computer-readable date always use UNIX timestamps or RFC 3339 (which are correctly and consistently supported).
I think my strategy for JavaScript going forward is to 'drop & run'.
Dates and times are insane, no matter the language.
Adding Temporal will only add to the chaos. Now there will be Date, moment, Luxon’s objects, and Temporal. See??? We fixed it!!!
Thanks!