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

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!

    new Date("2025-07-12 12:30:45 BST")

    new Date("2025-07-12 12:30:45 GMT")
    new Date("2025-07-12 12:30:45 UTC")
    new Date("2025-07-12 12:30:45 Z")

Oh hi! Thanks for the great quiz

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.

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.

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

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.

“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.

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

In other words

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

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.

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.

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.