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

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.

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.

> All they need to do is set Access-Control-Allow-Origin to allow websites to access it. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.

They can, but the major providers (read: the ones I would trust to update it) don't. The IERS doesn't [0], the USNO doesn't [1], IANA doesn't [2], and NIST uses FTP [3]. Keep in mind that these files are constantly being downloaded by various clients for NTP and whatnot, it's not like these providers want to restrict public access, they just don't bother to set the header that would allow JS requests.

> Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file.

From ECMA-262:

> It is required for time zone aware implementations (and recommended for all others) to use the time zone information of the IANA Time Zone Database https://www.iana.org/time-zones/.

Any browser that ships with a copy of tzdb, or knows where to find a copy from the OS, should have access to its leapseconds file. Unless you mean that all of them go solely through ICU and its data files? Which I suppose could be an obstacle unless ICU were to start exposing them.

[0] https://hpiers.obspm.fr/iers/bul/bulc/ntp/leap-seconds.list

[1] https://maia.usno.navy.mil/ser7/tai-utc.dat

[2] https://data.iana.org/time-zones/tzdb/leap-seconds.list

[3] ftp://ftp.boulder.nist.gov/pub/time/leap-seconds.list

I could, and that's what everyone typically ends up doing. But then I have to remember to go back and publish a new update whenever (and if ever) there's a new leap second, for every script I end up writing. I can't just write it so that it works on its own for the next decade without me poking at it.

Sure, but my gripe isn't even that we ought to change the "POSIX time by default" status quo (the ship has long sailed that everyone counts durations by 'calendar seconds'), it's that the underlying libraries don't even provide enough information for "specialty applications" to reliably correct for it, short of perpetually updating it themselves.

When what you have is a pickaxe, everything looks like a rail...

Yep, I’ve been using this one which is lighter (20kB): https://github.com/fullcalendar/temporal-polyfill/

It is a lot more complex than moment, but only because there's a lot of inherent complexity to dates and times that moment just doesn't deal with. So you need to be explicit about whether you're dealing with dates, times, or datetime objects, whether or not the object you're working with has a timezone, etc. Where moment is generally designed to have a convenient API, Temporal is designed to have a correct API.

It’s a web standard api and very small weight. Highly recommend.

Didn't moment basically say in so many words, use Temporal?

The Date API is horrible

yep. i had a hell of a time building a scheduling system for a business that worked across timezones with the date API

Yeah, it effectively became a typed wrapper of a long epoch millis value. Generally treated as immutable by convention in my experience, although of course it technically wasn't as the setters were never removed.

It was hopelessly wrong initially, and got even worse when they added the horrible sql Date/Timestamp/etc classes.

With java.time though, it is the gold standard as far as I've seen.

Java's time and duration representations, heavily based on Joda, should be the standard that every language works towards.

It's just about perfect in every way. It makes it easy to do the right thing and it's very pleasant to read.

https://javaalmanac.io/jdk/1.1/api/java.util.Date.html

Once Chrome does, for many devs, you can simply enforce a version check and say "please use latest Chrome" and be done with it.

I just groked it before and thought "plain" in `Temporal.PlainDateTime` indicates some specific format instead of just being zoneless. It is actually always using ISO8601 fur build in toString conversions, so I don't really have anything to complain about.