Comment by tshaddox

To be fair, the new opt-in "use strict" here is "switch to Temporal". It's a new, stricter namespace object. Old Date code gets the old Date code quirks, new code gets the nice new Temporal API.

Internal modules would be handy in theory to maybe keep from having to dig through a thesaurus every time browsers decide to add a new, stricter version of an older API. Internal modules have even been proposed to TC-39 as a recommended way to continue to expand the JS API. Last I checked on that proposal it was stuck behind several concerns including:

1. Feature detection: detecting if Temporal available is as easy as `if ('Temporal' in globalThis) {}`, but detecting if a module import is missing is a bit harder. Right now the standard is that loading a module fails with an Error if one of its imports fails. You can work around that by doing a dynamic import inside a try/catch, but that's a lot of extra boilerplate compared to `const thingINeed = 'someApi' in globalThis ? someApi() : someApiPolyfill()`. I've seen multiple proposals on that front from extensions to import maps and `with { }` options on the import itself.

2. Bikeshedding (and lots of it): defining a URI scheme like `browser:` or `standard:` takes a bunch of thought on how you expand it. If it is just `browser:some-api` you run the risk of eventually polluting all the easy names in the exact way people worry about the risk of over-polluting `globalThis` (and in the way that it can be weirdly hard to find an available one-word name on npm), you've just moved the naming problem from one place to the other. On the other side, if you go down the road of something like `es-standard:https://tc39.es/ecma262/2025/v1/final-draft/Temporal`, even (especially) assuming users would mostly importmap that to something shorter you've recreated XMLNS URIs in a funny new hat and people who use JS all certainly have plenty of opinions on XMLNS URIs, many are very vocal in their hatred of it, but also they came out of a strong backwards incompatibility fixing desire exactly like this. (As they say time is a flat circle.)

> It would have been nice for other wide changes like this to have like a 'strict datetime'; directive which would opt you into using this corrected behavior.

That would be ugly, because you'd want some parts of your program (eg libraries) to use the old behaviour, and other parts might want the new behaviour. How would you minify multiple modules together if they all expect different behaviour from the standard library?

In my opinion the right way to do this is to have multiple constructors (as Obj-C, swift, C and rust all do). Eg:

    let d = new Date(...) // old behaviour (not recommended for new code)
    
    let d = Date.fromISOString(...) // fixed behaviour

I find it very unfortunate that browsers (or rather, the spec) do not support some kind of versioning. If we could declare which version of HTML, JS and CSS to use, it would allow for breaking changes without breaking the entire web.

There are so many (in hindsight bad) design choices and implementation accidents that currently exist in perpetuity because of backwards compatibility; the web would really benefit if every now and then we could shed old baggage.

directives sort of kinda work if you squint the eyes, but only as a crutch and only if you can't/don't want to change the API.

> Or they could go all in on internal modules, like how you can import `node:fs` now. They could include corrected versions of globals like `import Date from 'browser:date';`

This is what happened here, only the API changed as well

This was the approach Perl took and much as I love(d) that language, it do get pretty out of hand after a while if you wanted to adopt any newer or stricter language features.

Maybe something like rust's editions, where you can opt into a set of breaking changes made at a certain time.

I always found it weird when systems code dates as DateTime strings. There needs to be a different primitive for Date, which is inherently timezone-less, and DateTime, which does require a timezone.

After having a bunch of problems with dealing with Dates coded as DateTime, I've begun coding dates as a Date primitive, and wrote functions for calculation between dates ensuring that timezone never creeps its way into it. If there is ever a DateTime string in a Date column in the database, it's impossible to know what the date was supposed to be unless you know you normalized it at some point on the way up.

Then I found that a lot of DatePicker libraries, despite being in "DATE" picker mode, will still append a local timezone to its value. So I had to write a sanitizer for stripping out the TZ before sending up to the server.

That said, I am pretty excited about Temporal, it'll still make other things easier.

I mean... That's kinda how it works? More than once I've halfway forgotten birthdays of friends who live in timezones to my east, and then sent them a message saying "Happy birthday! (It still is where I am, lol)".

I'm not necessarily defending the implementation, just pointing out another way in which time is irreducibly ambiguous and cursed.

I agree with the "don't break the web" design principle, but I sometimes disagree with precisely where TC39 draws the line. There is obviously a cost to breaking old, unchanging websites. But there's also a cost to allowing old, unchanging websites to hold the entire web hostage. Balancing those costs is a subjective matter.

As far as I know, TC39 doesn't have any clear guidelines about how many websites or how many users must be affected in order to reject a proposed change to JavaScript behavior. Clearly there are breaking changes that are so insignificant that TC39 should ignore them (imagine a website with some JavaScript that simply iterates over every built-in API and crashes if any of them ever change).

Browsers should version their languages. They should say "if you use <html version="5.2"> or bigger, this is the behavior".

Somehow, the standard groups decided to remove the versioning that was there.

Nah, that's not a "sacrifice", but the only sane way. In the ideal case, clearly document the constructor with a warning that it's not ISO conformant and offer a ISO conformant alternative.

In my (unfortunate) experience, DateTime/Timezone handling is one of the things most prone to introduce sneaky, but far-reaching bugs as it is. Introducing such a behaviour change that (usually) won't fail-fast, will often seemingly continue working as before until it doesn't and is deceptively tricky to debug/pinpoint/fix ist just asking for a fast lane into chaos.

And even with JS going the extra mile on backwards compatibility, I don't think most other languages would introduce that kind of breaking change in that way either.

Have an optional parameter to opt in to the old behaviour and keep the new correct behaviour the default (without the parameter) seems like a decent choice.

Guessed 2 of the first 3 questions.

Got to question 4 and gave up:

    new Date("not a date")
    1) Invalid Date
    2) undefined
    3) Throws an error
    4) null

It's a common source of off-by-one date formatting bugs in client-rendered web apps, particularly ones that pass around "YYYY-MM-DD" date strings (common for OpenAPI JSON APIs).

  const dateStringFromApiResponse = "2026-01-12";
  const date = new Date(dateStringFromApiResponse);
  const formatter = new Intl.DateTimeFormat('en-US', { dateStyle: 'long' });
  formatter.format(new Date("2026-01-12"));

  // 'January 11, 2026'

UTC is a fine default time zone, but that doesn't matter here.

A datetime with a timezone and a datetime without one are two different things, both of them useful. My birthday does not have a time zone. My deadline does.

The company deadline for getting some document returned? It might or might not, that's policy.

Poetically: we are born free of time zones. We die bound to one.

This will result in incorrect behavior when, between converting to UTC and back to the original timezone, the timezone database has changed, which happens more often than you think.