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

by OuterVale • 1 year ago

409 236 1 year ago

schoen• 1 year 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!

2muchcoffeeman2• 1 year 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• 1 year 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.

notatoad2• 1 year 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.

malux85• 1 year 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.

stevage2• 1 year 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• 1 year ago

leipert• 1 year ago

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

samwho15• 1 year 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• 1 year 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=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!

mcv2• 1 year ago

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.

corey_moncure• 1 year ago

Javascript put me off a career in IT for 20 years, and even today I still avoid it like radioactive waste.

saghm3• 1 year ago

At the beginning of the quiz, the author noted the exact time zone their laptop is in, have at least one of the questions I got wrong because I didn't take that into account. Totally valid though, and I honestly felt like I should have recognized that it would come into play given how I noticed how specific it was before starting

samwho15• 1 year ago

It’s a mean thing for me to have done, and I did originally have an extra little disclaimer on the questions where it was relevant, but I removed it because it felt like the shock value was more funny.

croes3• 1 year ago

Why?

samwho15• 1 year 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. :)

croes3• 1 year 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• 1 year ago

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

agos5• 1 year 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

[2] https://chromestatus.com/feature/5668291307634688?ref=comput...

[3] https://github.com/WebKit/WebKit/pull/45603

bubblebeard• 1 year ago

Haha that was fun :D

Thanks!

torlok• 1 year 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• 1 year 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

jameshart6• 1 year ago

And now you have two problems

KaiMagnus• 1 year 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!

bsmth2• 1 year ago

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

samwho15• 1 year ago

It me.

bsmth2• 1 year ago

Oh hi! Thanks for the great quiz

netsharc3• 1 year 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.

ctxc2• 1 year ago

Good job Sam! Been a while since we spoke on Twitter, but good to see you here :)

sankalpmukim• 1 year 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• 1 year 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!!!

mcv2• 1 year ago

Too many standards? Time to add another one. This one will be final, I promise.

actinium2262• 1 year 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.

mnahkies3• 1 year 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.

samwho15• 1 year 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. :)

lukan4• 1 year 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• 1 year ago

A parser is supposed to reject invalid input, not generate semi-arbitrary outputs.

arp242• 1 year ago

The entire point of a parser is to parse unknown values. That's the entire job of a parser: take unstructured (usually string) data and turn it in to something structured, such as a date. If it can't do that reliably with error reporting then it's not a good parser on a very fundamental level.

There are so many valid and reasonable cases where this will bite you.

"Real-world data" from CSV files or XML files or whatnot (that you don't control) and sometimes they have errors in them, and it's useful to know when instead of importing wrong data.

You do something wrong by mistake and getting wrong/confusing behaviour that you literally never want, and then you need to debug where that's coming from.

The user gives you a date, you have no idea what they entered and you want to know if that's correct.

JonChesterfield• 1 year ago

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.

mnahkies3• 1 year ago

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.

Hilift• 1 year ago

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.

croes3• 1 year ago

Good luck with a random dependency or dependency of a dependency that doesn’t work that way.

mattmanser• 1 year ago

Every time someone says "just stick to UTC ISO 8601 strings / Unix timestamp", it's clear they've only worked with dates in very specific ways.

Try that tactic with FUTURE dates.

Meet at 7pm still means meet at 7pm when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.

And it's actually a more subtle problem. You actually need the context of the timezone in some applications. If your application is showing dinner reservations, for example, you want to display the time in the local time of the restaurant, not the local time of the user. You want to know when it's booked THERE, not where you happen to be right now. I want to know my booking is at 7pm, not 1pm because I happen to be in America right now.

So using GMT/UTC is not a panacea for all the date problems you face.

It's only a solution for dates in the past. And even then you might argue that sometimes it's worth also storing the local time of the user/thing the event happened to, or at the very least the timezone they were in when it happened in a separate field.

gpvos• 1 year ago

you want to display the time in the local time of the restaurant

Many European railway timetable amd booking websites fall foul of this.

NoInkling3• 1 year ago

The IANA timezone database does occasionally revise historical rules when relevant information comes to light. So you might have calculated that some historical figure died at such-and-such a time UTC (based on a documented local time), but actually that's inaccurate and you might not know because you haven't redone the calculation with the new rules.

josephg3• 1 year ago

Are any other languages more sane with this stuff? Because I've also been to this particular corner of hell. Also in a web app.

But - wouldn't this be just as horrible in Go or Rust or any other language? (Or god forbid, C?) Are there better timezone APIs in other languages than what you can find in NPM that make these problems any easier to deal with?

kapep• 1 year ago

when timezones change, countries make changes to when their summer time starts, etc. Which happens all the time.

The frequency in which time zones are changed surprised me the first time I looked it up. For a single country it's probably quite a big deal that doesn't happen too often. But internationally there are several changes each year. I think it was like 4-6 changes per year in the past decades.

whatevaa• 1 year ago

Databases like postgres need timezone stored separately anyway, so for scheduling store local time and time zone it was scheduled in separately.

alkonaut• 1 year ago

If you're passing raw/unvalidated user input to the date parser you're holding it wrong.

Oh absolutely. But the difference between a sane api and other APIs is that a sane one will fail in a sane way, ideally telling me I’m holding it wrong.

Especially: the key at every turn is to fail hard if there is anything even slightly wrong rather than do something potentially incorrect. Many JS apis seem designed to continue at any cost which is the fundamental problem. You never really want a NaN. You don’t want to coerce strings to [whatever].

BrandoElFollito• 1 year 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• 1 year 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• 1 year 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• 1 year 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.

norskeld2• 1 year 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/Refe...).

actinium2262• 1 year 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/jul...

bakkoting• 1 year ago

That's not the last progress update. Most recent is 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 IIRC.

norskeld2• 1 year 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...

wiseowise10• 1 year ago

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

rplnt• 1 year 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.

samwho15• 1 year 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• 1 year ago

date.getYear() => 125

If that’s not relevant, I don’t know what is.

wiseowise10• 1 year 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...

porridgeraisin4• 1 year ago

Today you should use getFullYear() => 2025

getYear() returns 125 as it was standard for dates to be offset from 1900 (which led to the Y2K problem). This behaviour should be maintained forever. "Nothing is more important than backwards compatibility"

Or rather, that should be mindset, so that we can achieve at least 90% backwards compatibility in practice.

const_cast5• 1 year ago

I think it is relevant, it's a part of the standard library. It's one problem that JS has one of the smallest standard libraries, and it's another that the parts it does have just... don't work.

And, "don't use the standard library" is not a solution. Well I mean it is, but it's not free - there's caveats. Which tools do you choose? How do you make sure all your engineers use the same ones? How do you make sure nobody touches the standard library? It's not an easy problem.

nikolayasdf123• 1 year ago

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

LoganDark• 1 year 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.

tialaramex5• 1 year 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.

nailer2• 1 year ago

What do you mean? false isn’t true in JavaScript.

Filligree• 1 year 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.

astura• 1 year ago

The string with the value of "false" evaluates to true.

In other words

If ("false") { /* You will be here */ }

wiseowise10• 1 year ago

Why wouldn’t “false” be true? It’s a non-empty string.

ascar• 1 year ago

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.

tialaramex5• 1 year ago

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.

camblomquist2• 1 year ago

edit: I'm mostly wrong here.

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.

bapak3• 1 year ago

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?

petee• 1 year ago

I found that too painful to get further than #14

bapak3• 1 year ago

I gave up on like 5 and I'm a JS developer. Who dreamed this API up?

efilife2• 1 year ago

may I ask how long are you programming in JS for?

wiradikusuma• 1 year ago

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.

dotnetcarpenter• 1 year 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• 1 year 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• 1 year 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• 1 year ago

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

kevincox• 1 year 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__alchemist2• 1 year ago

It's one of the [incorrect] answers to these questions: "Throws an error".

tobyhinloopen• 1 year ago

10 / 28 lol, that's sad

ivanjermakov• 1 year ago

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

pluc• 1 year ago

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

th0ma57• 1 year 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.

qsort2• 1 year 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.

fragmede• 1 year ago

the near decade of WAT snark

For today's lucky 10,000:

https://www.destroyallsoftware.com/talks/wat (2012)

teaearlgraycold5• 1 year ago

I maintain that TypeScript is probably the best language you’ll be able to get paid to write.

suprfnk• 1 year ago

C# pays fine

douglasisshiny• 1 year ago

Meh, I used to have that feeling, especially when discovering fp-ts and then effect (neither of which I've been paid to write), but after about four years, I'm tired of writing it period. The standard library for node is horrible; the ecosystem is okay but not great. And I don't even care for effect anymore. I also write go in my job and it's just okay, but the standard library is much better.

I've been playing around with rust in my free time and like it. I think it's a good FP middle ground. Gleam also looks interesting. But to your point I imagine there aren't many jobs paying for rust and practically none for Gleam.

soulofmischief• 1 year ago

I'd love to disagree, but every other language's ergonomics just seem so clunky or too magic, whereas with TS and the standard web APIs you have so much room to code how you see fit. Sure, I'd rather a LISP for purity but I'm a realist. If only Brandon Eich had really gotten his way, we'd have Scheme.

moomoo11• 1 year ago

Agree. While people argue and split hairs over X language is better than Y language (noobs if I’m being honest, even if they have 20 yr experience), one can ship actual products and make money using TS.

It’s a good language that scales quite well to the point where you can then extract specific parts to more performant languages.

99.9% of people won’t have that problem, so I think they should just use TS and solve problems.

Anyone else can be safely ignored and they can complain in the corner.

nialv72• 1 year ago

i was paid to write rust for a couple of years.

frizlab• 1 year ago

Swift is a bliss to write and easy to get paid to write it.

t-writescode• 1 year ago

As of the last couple years, you're probably not wrong. Basically every open role right now requires TypeScript, Node, Next.JS, etc.

bspammer• 1 year ago

Kotlin and even modern Java are both preferable for me. There’s no shortage of JVM roles.

andai• 1 year ago

People may forget what you did, but they'll remember how you made them feel. It's been years since I've used TS, but I remember it failing to solve about half the problems that I had with JS. I think they did the best they could given the constraints though.

This article is a good example. TS can't fix the underlying APIs, standard library etc.

the__alchemist2• 1 year 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.

NoInkling3• 1 year 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.

agos5• 1 year 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?

netsharc3• 1 year 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.

samwho15• 1 year ago

This should be fixed. Sorry about that.

tlogan• 1 year 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• 1 year ago

JavaScript is hilarious through and through.

superjan• 1 year ago

And don’t forget that Date objects are mutable!

jenscow• 1 year ago

28 reasons to not use the built-in Date class

fanf2• 1 year 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...

agos5• 1 year ago

yup. this goes together with the "0.1 + 0.2" outrage

saghm3• 1 year ago

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

samwho15• 1 year ago

I got a good laugh out of this.

omoikane• 1 year ago

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

aruggirello• 1 year ago

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

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

nebrelbug• 1 year ago

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

Alifatisk• 1 year ago

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

Kholin• 1 year ago

Day.js

efilife2• 1 year ago

This is really not a big deal. You never do this stuff in production before validating the input. Garbage in, garbage out

NoInkling3• 1 year ago

Temporal.

agos5• 1 year ago

if I were starting a new project today I would go with a Temporal polyfill

GloomyBoots• 1 year ago

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

vander_elst2• 1 year 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• 1 year 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).

stevage2• 1 year 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_elst2• 1 year 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.

samwho15• 1 year ago

A couple of other comments have noted, and Brendan Eich himself actually replied on Twitter (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.

BrendanEich• 1 year ago

Thanks. More info in this thread:

https://x.com/BrendanEich/status/1752615257615528205

a3w• 1 year ago

My firefox JS console has different answers to this quiz.

elendee• 1 year 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

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

Related Stories