24 ms·

New Date("wtf") – How well do you know JavaScript's Date class?

409 points by OuterVale 1y ago

ivanjermakov 1y ago
Lots of lessons in language design here. No explicit error return type and null bottom type create high ambiguity in such edge cases.
schoen 1y ago
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!
- 2muchcoffeeman 1y ago
  The problem is that you couldn’t start to guess all of these. It’s just random noise. Strings 32-49 are in the 2000s but 50 onwards are in the 1900. Burn it and start again.
  - spiffytech 1y ago
    > Burn it and start again Good news! The builtin Temporal API is on its way. It's widely regarded as a solid API, learning from some of the best time APIs in other languages. In terms of parsing, it looks like Temporal only accepts RFC 9557 strings (an extension of ISO 8601 / RFC 3339). Anything else throws an exception.
    - zelphirkalt 1y ago
      Bad news: shitty designed parts are here to stay, because people will cry for backwards compatibility.
      - pavel_lishin 1y ago
        Sure. But people don't have to keep using them. Of course... they will. Because there are going to be more outdated results on search engines for Date, instead of the Temporal API. But at least there's something positive coming!
  - notatoad 1y ago
    As is usual with these JS critiques, the problem is that you'd never do most of this. Yes, it's silly, but nobody passes random strings into the date constructor because all you really need to know is that the date constructor does weird shit with random strings. You don't need to burn it, you just need to never rely on the constructor for parsing user input. It all works fine as long as you know the structure of the data before you pass it in.
    - wewtyflakes 1y ago
      Those are both big qualifiers... 1. Know not to use the constructor. 2. Make assumptions about user input. Neither seem awesome.
      - samwho 1y ago
        Hopefully this quiz helps with the first point :)
    - 2muchcoffeeman 1y ago
      I don’t think this is a very good defence. Let’s say you started a date lib right now that would take random strings and do its best. Suppose you identify the string is only integers. What logic needs to be applied to make the example I pointed out make any sort of common sense?
      - notatoad 1y ago
        >Let’s say you started a date lib right now that would take random strings and do its best. why would you do that? that's a bad idea, and no matter what implementation you choose you will end up with some silly compromises like javascript has in it's date constructor. javascript's default choices are probably no better or worse than whatever choices you would make. if you're writing a date parser, the first thing you should do is come up with a better definition than "take random strings and do your best" unless you're putting an LLM behind it.
    - bevr1337 1y ago
- malux85 1y ago
  Yeah this is the curse of the intermediate developer at work The junior developer experiences nothing but errors, and struggles to get something over the line The intermediate developer adopts “reduce errors at all cost” mentality and their parsers are too helpful, they make too many assumptions, and you end up with the Date class type behaviour. The senior developer knows the deadliness of this, and designs a robust class that behaves consistently and errors early on invalid input.
- stevage 1y ago
  I can sympathise with the urge to write code that produces a valid answer if at all possible. Usually I can overcome that urge. It's curious that these designers could not.
4ndrewl 1y ago
Related: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
leipert 1y ago
10/28. Not bad. But probably also is implementation dependent: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- samwho 1y ago
  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 1y ago
    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=103527 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!
croes 1y ago
Why?
- samwho 1y ago
  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. :)
  - croes 1y ago
    But who came up with such a confusing „logic“? „0“ and „1“ are for years, everything above are month. Does the text parsing only work for English or other languages too?
worble 1y ago
So... any browser other than Firefox feel like shipping Temporal yet?
- agos 1y ago
  Deno supports it behind a flag[1] Chrome is implementing it[2] WebKit has an open PR[3] I found no reference to Node working on it and of course you can already use a polyfill (though it's quite heavy) [1] https://deno.com/blog/v1.40?ref=computus.org#temporal-api https://deno.com/blog/v1.40?ref=computus.org#temporal-api [2] https://chromestatus.com/feature/5668291307634688?ref=computus.org https://chromestatus.com/feature/5668291307634688?ref=comput... [3] https://github.com/WebKit/WebKit/pull/45603 https://github.com/WebKit/WebKit/pull/45603
bubblebeard 1y ago
Haha that was fun :D Thanks!
torlok 1y ago
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.
- 1oooqooq 1y ago
  so true. i coded security js code for a decade. right when the standard started to get the many updates. our system was just a really tiny subset of things you could use that worked safely (and predictably) across browsers. even after the updates, we only incorporated was array.filter and structuredcopy. everything else offered no real benefit and only added to the attack surface. and then came typescript. the biggest missed opportunity in js history. even today, good js is knowing you can only use 1% of the language, and even that with lot of care
- jameshart 1y ago
  And now you have two problems
KaiMagnus 1y ago
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!
bsmth 1y ago
Post by the author Sam Rose about it: https://bsky.app/profile/samwho.dev/post/3ltpdkr3bmk2o https://bsky.app/profile/samwho.dev/post/3ltpdkr3bmk2o
- samwho 1y ago
  It me.
  - bsmth 1y ago
    Oh hi! Thanks for the great quiz
    - samwho 1y ago
      You’re welcome!
  - netsharc 1y ago
    Fix the font for the description field that appears after someone picks an answer. On a normal Windows 10 install, the 0 (zero) is rendered identically to a lowercase o. If you're going to use fancy fonts at least make them webfonts.
    - samwho 1y ago
      This should be fixed. I picked fonts that are present on a wide variety of systems without having to be downloaded on page load. I just forgot some CSS to make sure numbers looked distinct. Fortunately someone sent me a PR with the right CSS.
  - ctxc 1y ago
    Good job Sam! Been a while since we spoke on Twitter, but good to see you here :)
    - samwho 1y ago
      Dangit I’m not recognising your username, sorry!
sankalpmukim 1y ago
9/28 - This was very good fun. Can't believe so much of the world's (important?) software is written in this toy language.
ilovethe80s 1y ago
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!!!
- mcv 1y ago
  Too many standards? Time to add another one. This one will be final, I promise.
- actinium226 1y ago
  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.
mnahkies 1y ago
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.
- samwho 1y ago
  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. :)
- lukan 1y ago
  "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.
  - colonwqbang 1y ago
    A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.
    - lukan 1y ago
      I agree on a theoretical level, but this is javascript and the web we are talking about. Invalid input is rather the norm in genereral, with the expectation the browser should still display something. But I do dream of a alternative timeline, in where the web evolved different.
deleted 1y ago
[deleted]
BrandoElFollito 1y ago
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.
hidroto 1y ago
4 / 28 "You would have scored higher by guessing at random." I think my strategy for JavaScript going forward is to 'drop & run'.
- plqbfbv 1y ago
  Same here! Too bad... I did guess at random! :D Anyway, after the experience trying to automate something with Google Sheets and wasting 4 hours just to discover that months start at 0 (in the context of parsing string dates and creating Date objects)... yep, no more JS for me.
- rkrisztian 1y ago
  If you guess at random, that's 25% probability to get the right answers, which gets you 7/28 points in average. I got 14/28 by trying hard and I still hate the result, but it's also true that the questions were largely impractical: noone parses dates like this in a real production app. We always validate the date format first. So noone should feel bad at their results.
wiseowise 1y ago
Cute. But things like these have tendency to be abused by “haha, js” crowd even if those things are irrelevant in practice.
- rplnt 1y ago
  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 1y ago
    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 1y ago
  date.getYear() => 125 If that’s not relevant, I don’t know what is.
  - wiseowise 1y ago
    > date.getFullYear() => 2025 `getYear` is literally deprecated everywhere and is not part of the spec. https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date.prototype.getfullyear https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
    - jameshart 1y ago
      Right, but it exists and looks correct and runs and won’t trigger any kind of error if you write code that uses it. This is what we call a ‘foot gun’.
      - hombre_fatal 1y ago
        On the other hand, you notice it the second you go use the software you just wrote to ensure it works. So it’s more like a foot dollar store water gun.
norskeld 1y ago
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/Reference/Global_Objects/Temporal https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).
- actinium226 1y ago
  They're certainly taking their sweet time with it. Reading the last progress update is mildly entertaining though: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/jul...
  - bakkoting 1y ago
    That's not the last progress update. Most recent is https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b70e19f306eb7f42b/meetings/2025-05/may-28.md#temporal-status-update-and-normative-change https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b7.... Implementations are ongoing and open source, so you can contribute if you want it to come faster! V8 is currently aiming to use https://github.com/boa-dev/temporal https://github.com/boa-dev/temporal IIRC.
  - norskeld 1y ago
    Ha-ha, thanks, I couldn't help but chuckle a bit at that intro. As for them taking their time... Well, yes, it's all rather sad, but I personally came to terms long ago with the snail's pace of JS proposals rolling out. And after all, working with dates and time zones is a rather complex matter in itself, so no judgment here. I've had to develop interfaces built entirely around date and time operations, and it was painful not so much because of the awful and broken date parsing in JS (although it definitely doesn't help), but rather because of the inherent complexity of how we represent calendar dates and times, and how we build abstractions around these representations. Definitely NOT looking forward to developing that booking system at work...
nikolayasdf123 1y ago
someone should make one for Python based on https://github.com/satwikkansal/wtfpython https://github.com/satwikkansal/wtfpython
LoganDark 1y ago
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.
tialaramex 1y ago
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.
- nailer 1y ago
  What do you mean? false isn’t true in JavaScript.
  - Filligree 1y ago
    “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.
    - deleted 1y ago
      [deleted]
    - nailer 1y ago
      Yes strings aren’t false unless they’re empty. Good thing.
      - deleted 1y ago
        [deleted]
      - macintux 1y ago
        Or, judging by other comments, “0”.
  - astura 1y ago
    The string with the value of "false" evaluates to true. In other words If ("false") { /* You will be here */ }
petee 1y ago
I found that too painful to get further than #14
- bapak 1y ago
  I gave up on like 5 and I'm a JS developer. Who dreamed this API up?
  - efilife 1y ago
    may I ask how long are you programming in JS for?
    - bapak 1y ago
      More than half of JS's own lifetime. I have great distaste for bad APIs and I'll go out of my way to not use them directly.
wiradikusuma 1y ago
Another thing is with timezone: https://github.com/date-fns/tz/issues/57 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.
dotnetcarpenter 1y ago
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?
- jzig 1y ago
  I bet you’re fun at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.
  - cyphar 1y ago
    Well, because fun is an amorphous concept defined to be human-specific, your comment should say: I am willing to (sarcastically) stake something of value on the premise that you are considered to be an interesting individual to interact with by your interlocutors and bystanders at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.
bagol 1y ago
I'm curious how would a formal spec define those behaviors.
- kevincox 1y ago
  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).
- the__alchemist 1y ago
  It's one of the [incorrect] answers to these questions: "Throws an error".
tobyhinloopen 1y ago
10 / 28 lol, that's sad
pluc 1y ago
Please don't make fun of JavaScript. Last time it happened, it replied with Node and now it's everywhere.
- th0ma5 1y ago
  Reminding me of the near decade of WAT snark where people thought undefined behaviour was a complete proof of the futility of technology when it was actually just people mistaking what technology is. Like it isn't funny that you can't carry water with a brick but for some reason everyone thought JavaScript should be able to accommodate every possible fuckup with a specific error or just fix it. A nice goal but not something to then feel smug about when it doesn't happen but it seemed to be a viral perspective that persisted for way too long.
  - qsort 1y ago
    People aren't mad that errors aren't fixed automatically, people are mad that the behavior is inconsistent and weird for no fundamental reason other than "that's how the interpreter worked when it all started and it's too late to fix the spec now". Python is a dynamic language as well and in many ways worse than JS, but [] + {} raises a type error. In JS [] + {} is an object and {} + [] is 0. It's not about being smug, it's that in no way, shape or form that makes any sense.
    - Izkata 1y ago
      First, [] + {} isn't an object, it's a string. Second, {} + [] isn't a type conversion issue, it's a parsing issue. That {} isn't an object, it's a code block. Assign {} to a variable to ensure it's an object, then do var + [] and you get the same result as the first one. When using an actual object in both of these, the type conversion makes sense: "+" acts on primitives like strings and numbers, so it has to convert them first. You're getting obj.toString() + array.toString() in either case. I'll admit the parsing issue here is odd, but most of the time peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works.
pinoy420 1y ago
[dead]
the__alchemist 1y ago
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.
- NoInkling 1y ago
  Yeah a lot of these popular libraries - including Moment, Luxon, Day.js - commit the sin of using a single type of object for distinct concepts. Absolute time, civil time? Basically the same thing right? Just shoehorn them both in.
  - agos 1y ago
    I can understand why JS' Date is the way it is, but Moment, and even more so Luxon and Day.js, have no excuses - Joda Time has been around since what, 2005?
netsharc 1y ago
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.
- samwho 1y ago
  This should be fixed. Sorry about that.
tlogan 1y ago
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.
genman 1y ago
JavaScript is hilarious through and through.
superjan 1y ago
And don’t forget that Date objects are mutable!
jenscow 1y ago
28 reasons to not use the built-in Date class
fanf2 1y ago
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/java/util/Date.html#parse(java.lang.String) https://docs.oracle.com/en/java/javase/21/docs/api/java.base...
- agos 1y ago
  yup. this goes together with the "0.1 + 0.2" outrage
saghm 1y ago
I scored what I have to assume is November 28, 2000.
- samwho 1y ago
  I got a good laugh out of this.
omoikane 1y ago
What I have learned is that "new Date(...)" never throws errors, and you would have to do something like "new Date(...).toISOString()".
aruggirello 1y ago
See also: "Falsehoods programmers believe about time and time zones": https://news.ycombinator.com/item?id=11515125 https://news.ycombinator.com/item?id=11515125
animanoir 1y ago
[dead]
nebrelbug 1y ago
I got 11/28, feeling pretty proud of myself honestly
Alifatisk 1y ago
So what’s the consensus on the solution to this chaos? MomentJs? LuxonsJs? Temporal?
- Kholin 1y ago
  Day.js
- efilife 1y ago
  This is really not a big deal. You never do this stuff in production before validating the input. Garbage in, garbage out
- NoInkling 1y ago
  Temporal.
- agos 1y ago
  if I were starting a new project today I would go with a Temporal polyfill
GloomyBoots 1y ago
Any explanation for ignoring parenthetical text? Is this maybe indirectly inherited from RFC 822?
vander_elst 1y ago
One thing I wonder is how could this have happened. It seems that this what a herd of absolute beginners would come up with: strong inconsistency and a bunch of heuristic that are not composable. But I imagine this was not the result of a bunch of beginners, what were the forces that lead to such a situation?
- xmprt 1y ago
  When a language allows operator overriding or doesn't have static typing, you can end up with situations like this where a single method does 10 different things for 10 different use-cases. Even Java and C++ aren't a stranger to APIs like this (although not nearly as bad).
- stevage 1y ago
  To be somewhat fair, most of what this is poking fun at is the parsing of strings that do not remotely resemble actual dates. It's very edge case behaviour. Yes, it'd be nice if the edge cases did something more predictable, like all just fail with an error, but unless you're doing something silly like passing whatever a user writes straight into Date.parse() it isn't going to matter. Realistically, you're going to use an actual date library, because even the good bits of Date are pretty bad.
  - vander_elst 1y ago
    > parsing of strings that do not remotely resemble actual dates. But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.
- samwho 1y ago
  A couple of other comments have noted, and Brendan Eich himself actually replied on Twitter (https://x.com/brendaneich/status/1944156296212886005?s=46 https://x.com/brendaneich/status/1944156296212886005?s=46), to say that it was a copy of Java’s Date class behaviour. I haven’t dug into the history of that, though.
a3w 1y ago
My firefox JS console has different answers to this quiz.
elendee 1y ago
personal take: store dates as bigints. rendering them is just a user interface issue. no need for Date parsing except to play nicely with legacy codebases. Milliseconds are your friend

409 points by OuterVale 1y ago

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

schoen 1y ago

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!

2muchcoffeeman 1y ago
The problem is that you couldn’t start to guess all of these. It’s just random noise. Strings 32-49 are in the 2000s but 50 onwards are in the 1900. Burn it and start again.
- spiffytech 1y ago
  > Burn it and start again Good news! The builtin Temporal API is on its way. It's widely regarded as a solid API, learning from some of the best time APIs in other languages. In terms of parsing, it looks like Temporal only accepts RFC 9557 strings (an extension of ISO 8601 / RFC 3339). Anything else throws an exception.
  - zelphirkalt 1y ago
    Bad news: shitty designed parts are here to stay, because people will cry for backwards compatibility.
    - pavel_lishin 1y ago
      Sure. But people don't have to keep using them. Of course... they will. Because there are going to be more outdated results on search engines for Date, instead of the Temporal API. But at least there's something positive coming!
- notatoad 1y ago
  As is usual with these JS critiques, the problem is that you'd never do most of this. Yes, it's silly, but nobody passes random strings into the date constructor because all you really need to know is that the date constructor does weird shit with random strings. You don't need to burn it, you just need to never rely on the constructor for parsing user input. It all works fine as long as you know the structure of the data before you pass it in.
  - wewtyflakes 1y ago
    Those are both big qualifiers... 1. Know not to use the constructor. 2. Make assumptions about user input. Neither seem awesome.
    - samwho 1y ago
      Hopefully this quiz helps with the first point :)
  - 2muchcoffeeman 1y ago
    I don’t think this is a very good defence. Let’s say you started a date lib right now that would take random strings and do its best. Suppose you identify the string is only integers. What logic needs to be applied to make the example I pointed out make any sort of common sense?
    - notatoad 1y ago
      >Let’s say you started a date lib right now that would take random strings and do its best. why would you do that? that's a bad idea, and no matter what implementation you choose you will end up with some silly compromises like javascript has in it's date constructor. javascript's default choices are probably no better or worse than whatever choices you would make. if you're writing a date parser, the first thing you should do is come up with a better definition than "take random strings and do your best" unless you're putting an LLM behind it.
  - bevr1337 1y ago
malux85 1y ago
Yeah this is the curse of the intermediate developer at work The junior developer experiences nothing but errors, and struggles to get something over the line The intermediate developer adopts “reduce errors at all cost” mentality and their parsers are too helpful, they make too many assumptions, and you end up with the Date class type behaviour. The senior developer knows the deadliness of this, and designs a robust class that behaves consistently and errors early on invalid input.
stevage 1y ago
I can sympathise with the urge to write code that produces a valid answer if at all possible. Usually I can overcome that urge. It's curious that these designers could not.

4ndrewl 1y ago

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

leipert 1y ago

10/28. Not bad. But probably also is implementation dependent: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/parse#non-standard_date_strings https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

samwho 1y ago
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 1y ago
  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=103527 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!

croes 1y ago

Why?

samwho 1y ago
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. :)
- croes 1y ago
  But who came up with such a confusing „logic“? „0“ and „1“ are for years, everything above are month. Does the text parsing only work for English or other languages too?

worble 1y ago

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

agos 1y ago
Deno supports it behind a flag[1] Chrome is implementing it[2] WebKit has an open PR[3] I found no reference to Node working on it and of course you can already use a polyfill (though it's quite heavy) [1] https://deno.com/blog/v1.40?ref=computus.org#temporal-api https://deno.com/blog/v1.40?ref=computus.org#temporal-api [2] https://chromestatus.com/feature/5668291307634688?ref=computus.org https://chromestatus.com/feature/5668291307634688?ref=comput... [3] https://github.com/WebKit/WebKit/pull/45603 https://github.com/WebKit/WebKit/pull/45603

bubblebeard 1y ago

Haha that was fun :D Thanks!

torlok 1y ago

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.

1oooqooq 1y ago
so true. i coded security js code for a decade. right when the standard started to get the many updates. our system was just a really tiny subset of things you could use that worked safely (and predictably) across browsers. even after the updates, we only incorporated was array.filter and structuredcopy. everything else offered no real benefit and only added to the attack surface. and then came typescript. the biggest missed opportunity in js history. even today, good js is knowing you can only use 1% of the language, and even that with lot of care
jameshart 1y ago
And now you have two problems

KaiMagnus 1y ago

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!

bsmth 1y ago

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

samwho 1y ago
It me.
- bsmth 1y ago
  Oh hi! Thanks for the great quiz
  - samwho 1y ago
    You’re welcome!
- netsharc 1y ago
  Fix the font for the description field that appears after someone picks an answer. On a normal Windows 10 install, the 0 (zero) is rendered identically to a lowercase o. If you're going to use fancy fonts at least make them webfonts.
  - samwho 1y ago
    This should be fixed. I picked fonts that are present on a wide variety of systems without having to be downloaded on page load. I just forgot some CSS to make sure numbers looked distinct. Fortunately someone sent me a PR with the right CSS.
- ctxc 1y ago
  Good job Sam! Been a while since we spoke on Twitter, but good to see you here :)
  - samwho 1y ago
    Dangit I’m not recognising your username, sorry!

sankalpmukim 1y ago

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

ilovethe80s 1y ago

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

mcv 1y ago
Too many standards? Time to add another one. This one will be final, I promise.
actinium226 1y ago
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.

mnahkies 1y ago

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.

samwho 1y ago
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. :)
lukan 1y ago
"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.
- colonwqbang 1y ago
  A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.
  - lukan 1y ago
    I agree on a theoretical level, but this is javascript and the web we are talking about. Invalid input is rather the norm in genereral, with the expectation the browser should still display something. But I do dream of a alternative timeline, in where the web evolved different.

deleted 1y ago

[deleted]

BrandoElFollito 1y ago

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.

hidroto 1y ago

4 / 28 "You would have scored higher by guessing at random." I think my strategy for JavaScript going forward is to 'drop & run'.

plqbfbv 1y ago
Same here! Too bad... I did guess at random! :D Anyway, after the experience trying to automate something with Google Sheets and wasting 4 hours just to discover that months start at 0 (in the context of parsing string dates and creating Date objects)... yep, no more JS for me.
rkrisztian 1y ago
If you guess at random, that's 25% probability to get the right answers, which gets you 7/28 points in average. I got 14/28 by trying hard and I still hate the result, but it's also true that the questions were largely impractical: noone parses dates like this in a real production app. We always validate the date format first. So noone should feel bad at their results.

wiseowise 1y ago

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

rplnt 1y ago
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 1y ago
  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 1y ago
date.getYear() => 125 If that’s not relevant, I don’t know what is.
- wiseowise 1y ago
  > date.getFullYear() => 2025 `getYear` is literally deprecated everywhere and is not part of the spec. https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date.prototype.getfullyear https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec...
  - jameshart 1y ago
    Right, but it exists and looks correct and runs and won’t trigger any kind of error if you write code that uses it. This is what we call a ‘foot gun’.
    - hombre_fatal 1y ago
      On the other hand, you notice it the second you go use the software you just wrote to ensure it works. So it’s more like a foot dollar store water gun.

norskeld 1y ago

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/Reference/Global_Objects/Temporal https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...).

actinium226 1y ago
They're certainly taking their sweet time with it. Reading the last progress update is mildly entertaining though: https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/july-30.md#temporal-update--bug-fixes https://github.com/tc39/notes/blob/HEAD/meetings/2024-07/jul...
- bakkoting 1y ago
  That's not the last progress update. Most recent is https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b70e19f306eb7f42b/meetings/2025-05/may-28.md#temporal-status-update-and-normative-change https://github.com/tc39/notes/blob/d5b5db6969359fad11b6898b7.... Implementations are ongoing and open source, so you can contribute if you want it to come faster! V8 is currently aiming to use https://github.com/boa-dev/temporal https://github.com/boa-dev/temporal IIRC.
- norskeld 1y ago
  Ha-ha, thanks, I couldn't help but chuckle a bit at that intro. As for them taking their time... Well, yes, it's all rather sad, but I personally came to terms long ago with the snail's pace of JS proposals rolling out. And after all, working with dates and time zones is a rather complex matter in itself, so no judgment here. I've had to develop interfaces built entirely around date and time operations, and it was painful not so much because of the awful and broken date parsing in JS (although it definitely doesn't help), but rather because of the inherent complexity of how we represent calendar dates and times, and how we build abstractions around these representations. Definitely NOT looking forward to developing that booking system at work...

nikolayasdf123 1y ago

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

LoganDark 1y ago

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.

tialaramex 1y ago

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.

nailer 1y ago
What do you mean? false isn’t true in JavaScript.
- Filligree 1y ago
  “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.
  - deleted 1y ago
    [deleted]
  - nailer 1y ago
    Yes strings aren’t false unless they’re empty. Good thing.
    - deleted 1y ago
      [deleted]
    - macintux 1y ago
      Or, judging by other comments, “0”.
- astura 1y ago
  The string with the value of "false" evaluates to true. In other words If ("false") { /* You will be here */ }

petee 1y ago

I found that too painful to get further than #14

bapak 1y ago
I gave up on like 5 and I'm a JS developer. Who dreamed this API up?
- efilife 1y ago
  may I ask how long are you programming in JS for?
  - bapak 1y ago
    More than half of JS's own lifetime. I have great distaste for bad APIs and I'll go out of my way to not use them directly.

wiradikusuma 1y ago

Another thing is with timezone: https://github.com/date-fns/tz/issues/57 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.

dotnetcarpenter 1y ago

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?

jzig 1y ago
I bet you’re fun at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.
- cyphar 1y ago
  Well, because fun is an amorphous concept defined to be human-specific, your comment should say: I am willing to (sarcastically) stake something of value on the premise that you are considered to be an interesting individual to interact with by your interlocutors and bystanders at socially coordinated gatherings of individuals convened for the explicit purpose of engaging in recreational, celebratory, or convivial activities, often characterized by the consumption of food and beverages, the enjoyment of music or other entertainments, and the collective participation in structured or unstructured merriment.

bagol 1y ago

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

kevincox 1y ago
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).
the__alchemist 1y ago
It's one of the [incorrect] answers to these questions: "Throws an error".

tobyhinloopen 1y ago

10 / 28 lol, that's sad

pluc 1y ago

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

th0ma5 1y ago
Reminding me of the near decade of WAT snark where people thought undefined behaviour was a complete proof of the futility of technology when it was actually just people mistaking what technology is. Like it isn't funny that you can't carry water with a brick but for some reason everyone thought JavaScript should be able to accommodate every possible fuckup with a specific error or just fix it. A nice goal but not something to then feel smug about when it doesn't happen but it seemed to be a viral perspective that persisted for way too long.
- qsort 1y ago
  People aren't mad that errors aren't fixed automatically, people are mad that the behavior is inconsistent and weird for no fundamental reason other than "that's how the interpreter worked when it all started and it's too late to fix the spec now". Python is a dynamic language as well and in many ways worse than JS, but [] + {} raises a type error. In JS [] + {} is an object and {} + [] is 0. It's not about being smug, it's that in no way, shape or form that makes any sense.
  - Izkata 1y ago
    First, [] + {} isn't an object, it's a string. Second, {} + [] isn't a type conversion issue, it's a parsing issue. That {} isn't an object, it's a code block. Assign {} to a variable to ensure it's an object, then do var + [] and you get the same result as the first one. When using an actual object in both of these, the type conversion makes sense: "+" acts on primitives like strings and numbers, so it has to convert them first. You're getting obj.toString() + array.toString() in either case. I'll admit the parsing issue here is odd, but most of the time peoples' complaints about javascript type coercion is that they simply never bothered to learn how it works.

pinoy420 1y ago

[dead]

the__alchemist 1y ago

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.

NoInkling 1y ago
Yeah a lot of these popular libraries - including Moment, Luxon, Day.js - commit the sin of using a single type of object for distinct concepts. Absolute time, civil time? Basically the same thing right? Just shoehorn them both in.
- agos 1y ago
  I can understand why JS' Date is the way it is, but Moment, and even more so Luxon and Day.js, have no excuses - Joda Time has been around since what, 2005?

netsharc 1y ago

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.

samwho 1y ago
This should be fixed. Sorry about that.

tlogan 1y ago

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.

genman 1y ago

JavaScript is hilarious through and through.

superjan 1y ago

And don’t forget that Date objects are mutable!

jenscow 1y ago

28 reasons to not use the built-in Date class

fanf2 1y ago

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/java/util/Date.html#parse(java.lang.String) https://docs.oracle.com/en/java/javase/21/docs/api/java.base...

agos 1y ago
yup. this goes together with the "0.1 + 0.2" outrage

saghm 1y ago

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

samwho 1y ago
I got a good laugh out of this.

omoikane 1y ago

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

aruggirello 1y ago

See also: "Falsehoods programmers believe about time and time zones": https://news.ycombinator.com/item?id=11515125 https://news.ycombinator.com/item?id=11515125

animanoir 1y ago

[dead]

nebrelbug 1y ago

I got 11/28, feeling pretty proud of myself honestly

Alifatisk 1y ago

So what’s the consensus on the solution to this chaos? MomentJs? LuxonsJs? Temporal?

Kholin 1y ago
Day.js
efilife 1y ago
This is really not a big deal. You never do this stuff in production before validating the input. Garbage in, garbage out
NoInkling 1y ago
Temporal.
agos 1y ago
if I were starting a new project today I would go with a Temporal polyfill

GloomyBoots 1y ago

Any explanation for ignoring parenthetical text? Is this maybe indirectly inherited from RFC 822?

vander_elst 1y ago

One thing I wonder is how could this have happened. It seems that this what a herd of absolute beginners would come up with: strong inconsistency and a bunch of heuristic that are not composable. But I imagine this was not the result of a bunch of beginners, what were the forces that lead to such a situation?

xmprt 1y ago
When a language allows operator overriding or doesn't have static typing, you can end up with situations like this where a single method does 10 different things for 10 different use-cases. Even Java and C++ aren't a stranger to APIs like this (although not nearly as bad).
stevage 1y ago
To be somewhat fair, most of what this is poking fun at is the parsing of strings that do not remotely resemble actual dates. It's very edge case behaviour. Yes, it'd be nice if the edge cases did something more predictable, like all just fail with an error, but unless you're doing something silly like passing whatever a user writes straight into Date.parse() it isn't going to matter. Realistically, you're going to use an actual date library, because even the good bits of Date are pretty bad.
- vander_elst 1y ago
  > parsing of strings that do not remotely resemble actual dates. But this is somehow my point, what were the reasons that lead to parse those strings as dates. I guess the answer is usually legacy, but in that "legacy" why did someone need to take those decisions? My naive way of parsing dates would be to reject everything that doesn't have a well defined format while the format is well defined and at least somehow composable, but here someone had the need (I hope the had the need) to parse these seemingly random strings, I wonder why.
samwho 1y ago
A couple of other comments have noted, and Brendan Eich himself actually replied on Twitter (https://x.com/brendaneich/status/1944156296212886005?s=46 https://x.com/brendaneich/status/1944156296212886005?s=46), to say that it was a copy of Java’s Date class behaviour. I haven’t dug into the history of that, though.

a3w 1y ago

My firefox JS console has different answers to this quiz.

elendee 1y ago

personal take: store dates as bigints. rendering them is just a user interface issue. no need for Date parsing except to play nicely with legacy codebases. Milliseconds are your friend