Please don't make fun of JavaScript. Last time it happened, it replied with Node and now it's everywhere.

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!

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.

I use iso strings for dates in JS, because they're such a trap. (As evidenced by even the first few quiz questions here). Moment, a popular alternative, is as bad in many ways. It conflates "date", "time", and "datetime", which causes so much trouble. The explanation I've heard is "time" and "date" shouldn't exist, which is, semantically, incompatible with my experiences.

10/28. Not bad. But probably also is implementation dependent: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Scored 17/28. Thank you, this is absolutely cursed! It's probably a good time to go and check out the Temporal stuff (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).

I scored what I have to assume is November 28, 2000.

4 / 28 "You would have scored higher by guessing at random."

I think my strategy for JavaScript going forward is to 'drop & run'.

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.

Post by the author Sam Rose about it: https://bsky.app/profile/samwho.dev/post/3ltpdkr3bmk2o

JavaScript’s Date class is a fairly straight port from Java, including most of the WAT in this quiz https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

So... any browser other than Firefox feel like shipping Temporal yet?

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!

The description field uses a typeface that obnoxiously renders 0 (zero) to look like^W^W (upon further investigation: be identical to) lowercase o...

At least on my pretty standard Windows 10 system. No idea which ones of the fonts Avenir, Montserrat, Corbel, URW Gothic, source-sans-pro, sans-serif is being used.

What I have learned is that "new Date(...)" never throws errors, and you would have to do something like "new Date(...).toISOString()".

Cute. But things like these have tendency to be abused by “haha, js” crowd even if those things are irrelevant in practice.

Another thing is with timezone: https://github.com/date-fns/tz/issues/57

I'm not sure if it's caused by JavaScript quirkiness under the hood or a bug in the library, but it's mindblowing.

Cool.

The first set of questions are logical and make some sense. But then there come questions asking you similar but with slightly different values.

And that’s when everything stops making sense.

And don’t forget that Date objects are mutable!

I'm curious how would a formal spec define those behaviors.

Lots of lessons in language design here. No explicit error return type and null bottom type create high ambiguity in such edge cases.

This is one of the reasons that I, an amateur dev, never touch dates other than via date-fns or other date libs.

Dates and times are insane, no matter the language.

I found that too painful to get further than #14

9/28 - This was very good fun. Can't believe so much of the world's (important?) software is written in this toy language.

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?

28 reasons to not use the built-in Date class

See also: "Falsehoods programmers believe about time and time zones":

https://news.ycombinator.com/item?id=11515125

someone should make one for Python based on https://github.com/satwikkansal/wtfpython

Related: https://www.destroyallsoftware.com/talks/wat

JavaScript is hilarious through and through.

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!!!

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.

Haha that was fun :D

Thanks!

Why?

10 / 28 lol, that's sad

[dead]

[dead]

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.