// Unless, of course, you separate the year, month, and date with hyphens.
  // Then it gets the _day_ wrong.
  console.log( new Date('2026-01-02') );
  // Result: Date Thu Jan 01 2026 19:00:00 GMT-0500 (Eastern Standard Time)

What's actually happening here is a comedy of errors. JavaScript is interpreting that particular string format ("YYYY-MM-DD") as an ISO 8601 date-only form. ISO 8601 specifies that if no time zone designator is provided, the time is assumed to be in local time. The ES5 spec authors intended to match ISO 8601 behavior, but somehow accidentally changed this to 'The value of an absent time zone offset is “Z”' (UTC).

Years later, they had realized their mistakes, and attempted to correct it in ES2015. And you can probably predict what happened. When browsers shipped the correct behavior, they got too many reports about websites which were relying on the previous incorrect behavior. So it got completely rolled back, sacrificed to the altar of "web compatibility."

For more info, see the "Broken Parser" section towards the bottom of this article:

https://maggiepint.com/2017/04/11/fixing-javascript-date-web...

This is why I don't understand the lack of directives.

'use strict'; at the top of a file was ubiquitous for a long time and it worked. It didn't force rolling back incompatibilities, it let you opt into a stricter parsing of JavaScript.

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.

They couldn't and shouldn't do this sort of thing for all changes, but for really major changes to the platform this would be an improvement.

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';`

has corrected behavior, for example

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

This. Don't break old code, just provide new best practices.

Update linters (or ideally first class language rules, like in Rust's "edition"s), to gradually kill off old behavior. Without having to do a decade long Python 2 -> 3 migration.

Temporal is nice. It learned from the many failures and dead bodies that came before it. And it had lots of good implementations to look at: Joda Time, Chrono, etc.

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.

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

How does it get out of hand?

FWIW, I just do `use v5.32;` or similar to opt-in to everything from that version.

https://perldoc.perl.org/functions/use#use-VERSION

Of course, if you instead want to pick-and-choose features, then I can see the list growing large.

Sometimes a date is just a date. Your birthday is on a date, it doesn't shift by x hours because you moved to another state.

The old Outlook marked birthdays as all-day events, but stored the value with time-zone, meaning all birthdays of people whose birthday I stored in Belgium were now shifted as I moved to California...

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.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

E.G. in a conversation "Lets open the shop at 9am every day that it isn't closed." Is a fairly simple recurrence, with some exceptions*. If timezones change the scheduled time remains evaluated again on each day.

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

The riddle explanation was something like: A baby is born in New York City at 12:15 AM on January 1. Thirty minutes later, another baby is born in Los Angeles, where the local time is 9:45 PM on December 31. Although the New York baby is actually older by 30 minutes, the calendar dates make it appear as though the Los Angeles baby was born first.

The timezones thing, of course, is just a way to have the younger twin be born "a year ahead" of the older twin by having their births be in two different timezones. Only practical way that would happen would be aboard a ship, because 1) babies born aboard an airplane would probably end up using the time zone of departure or of destination for their birth, and so twins would not be counted as being born in different time zones. And 2) any land-based transportation such as a car or a train would likely pull over (or in the case of a train, let the pregnant woman off at the nearest station) so that the woman giving birth doesn't have to do so in a moving vehicle. So a ship is the only moving vehicle where this kind of thing could likely happen, as there's no option of getting off in the middle of the ocean. It could happen while crossing time zones east-to-west, but crossing the International Date Line west-to-east makes more of an interesting thought experiment.

Yes, I've given this silly joke scenario way more thought than it really deserves. :-)

Doesn't even have to be the International Date line, any two timezones work.

But it does. My brother moved to the US for a few years. So we’d send him birthday wishes on the day of his birthday (Australia time), and he’d get them the day before his birthday (his time). Now he’s moved back to Australia, the same thing happens in reverse-he gets birthday wishes from his American friends the day after his birthday.

My wife has lots of American friends on Facebook (none of whom she knows personally, all people she used to play Farmville with)-and she has them wishing her a happy birthday the day after her birthday too. Maybe she’s doing the same to them in reverse.

What should they have done instead? Force everybody to detect browser versions and branch based on that, like in the olden days of IE5?

(Serious question, maybe I'm overlooking some smart trick.)

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

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

That's basically why they never did anything like "use strict" again.

IMO, that's a bad choice. Giving yourself the ability to have new behavior and features based on a version is pretty natural and how most programming languages evolve. Having perpetual backwards and fowards compatibility at all times is both hard to maintain and makes it really hard to fix old mistakes.

The only other reason they might have chosen this route is because it's pretty hard to integrate the notion of compatibility levels into minifiers.

Backwards compatibility is a large part of the point of the Web.

You could version everything at whatever granularity you like, but over time that accumulates ("bug 3718938: JS gen24 code incorrectly handles Date math as if it were gen25-34", not to mention libraries that handle some versions but not others and then implicitly pass their expectations around via the objects they create so your dependency resolver has to look at the cross product of versions from all your depencies...)

One can't fathom how weird JS Date can be.

Got to question 4 and gave up:

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

    new Date(Math.E)
    new Date(-1)

Is there any other instance of the standard JS library returning an error object instead of throwing one? I can't think of any.

But besides that I think you're right, Invalid Date is pretty weird and I somehow never ran into it.

One consequence is you can still call Date methods on the invalid date object and then you get NaN from the numeric results.

    > let invalid = new Date('not a date')
    > invalid
    Invalid Date
    > invalid instanceof Date
    true

    > invalid.getTime()
    NaN

    > invalid === new Date(NaN)
    false

This is just because a JS Date is an object and have nothing to do with the inner representation.

    > new Date(0) === new Date(0)
    false

This feels like something that must be the root of innumerable small and easily overlooked bugs out there.

  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'

Basically just extracting numbers from string index or regex and rearranging them to a string Excel would recognize

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.

That seems subjective

Would it have been nice if the Date object had been immutable? Sure, but the fact that changing the mutable object does indeed change the object shouldn't be a shock

If I had the guess, I'd say it's a combination of:

- the difference between the mental model and the implementation. Dates are objects but "feel" like values: dates are parsed from a single value, and when stored/printed they collapse back to a single value (as opposed to custom objects which are generally a bag of properties, and when printed/stored they still look like an object)

- most common date operations causes the original date object to be mutated, which implicitly causes developers to mutate the passed value even if that's not what they explicitly meant

So the default combination is a calling code that expects date to be treated as a value, and the called code accidentally mutating the data because it's convenient to do so. If anything then causes the original value to be saved back in the db, the data gets corrupted.

Most experienced developers will remember to make a copy of the date object both in the calling code and in the receiving code, but the default remains dangerously easy to get wrong.

I would like to add, that both variable and object immutability should be the default, and mutability should have a keyword, not other way around how in C++ and Java.

(The context is that I want to write some JS tools for astronomical calculations, but UTC conversions need leap-second info, so this trend makes it impossible to write something that Just Works™.)

  >only UTC is in-scope for this project

  >tools for astronomical calculations

As you allude to, the correct time scale for this purpose would be TBD (aka Barycentric Dynamical Time), which applies relativistic corrections to act like the atomic clock is fixed at the barycentre of the Solar system. This is the only clock that actually runs "smoothly" for the purposes of astronomical calculations.

https://stjarnhimlen.se/comp/time.html

That is completely wrong. UTC seconds are exactly SI seconds, which are all the same uniform length (defined by quorum of atomic clocks).

WDYM by this? Why does the SOP prevent a website from hosting a leap seconds file? All they need to do is set Access-Control-Allow-Origin to allow websites to access it. Or provide it as a JS file—in which case no headers are necessary at all. All the SOP prevents is you hotlinking someone else's leap-seconds file and using their bandwidth without their opt-in.

> Meanwhile, browsers update on a cadence more than sufficient to keep an up-to-date copy

Is this true? I don't know any browser right now that ships with a copy of a leapseconds data file. Adding such a data file and keeping it up to date would probably be a pretty non-trivial task for new browser developers—just for something the browser will never end up using itself. It's not like the ICU/CLDR files where browsers are going to need them anyway for rendering their own user-interface components.

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

You could even write a Cloudflare Worker or a Val on val.town to do that, and add a bit of caching on top so you don't hit your providers too often.

This doesn't make sense on at least two different levels.

First, pedantically, the definition of UTC as a time scale is that it includes leap seconds. So if you're committed to UTC, then you're supporting leap seconds.

Second, and to more broadly address your point, you should say, "they're too committed to 'only the POSIX time scale is in-scope for this project.'" That more accurately captures the status quo and also intimates the problem: aside from specialty applications, basically everything is built on POSIX time, which specifically ignores the existence of leap seconds.

I say this as someone who had leap second support working in a pre-release version of Jiff[1] (including reading from leapsecond tzdb data) but ripped it out for reasons.[2]

[1]: https://github.com/BurntSushi/jiff

[2]: https://github.com/BurntSushi/jiff/issues/7

That's part of it: If I were writing a standalone program that could extract info from tzdb or whatever, I'd happily jump through those hoops, and not bother anyone else's libraries. I don't really care about the ergonomics. But for JS scripts in particular, there is no information available that is not provided by either the browser APIs or someone's server. And such servers are not in great supply.

Anything using GPS as lock references to synchronize stuff that needs to be aligned to the millisecond absolutely cannot tolerate stuff like “the leap second smear”.

That's probably because you only need leap second accuracy in niche use cases, like astronomy or GPS. In JavaScript specifically, that kind of accuracy isn't needed for 99% of client-side use cases. Most date-time libraries work with POSIX time which assumes 86,400 seconds each day.

That’s because human time keeping doesn’t use leap seconds.

2 things it got right:

1. Like the article a great API - Time.current.in_time_zone('America/Los_Angeles') + 3.days - 4.months + 1.hour

2. Rails overloads Ruby's core library Time. You're in 1 object the whole time no swap/wondering.

In the py world, pendulum is close but just like the article, it's cumbersome as it's still a separate obj (i.e. Temporal vs Date) and so you need to "figure out" what you have to manipulate or need to cast it first.

Overloading the core libs is dangerous for a whole host of reasons but for the end developer it's a pleasure to use.

If we could just do `new Date().add({ days: 1})` it would be so easier.

Is this what it looks like? A specific concept like time units being defined as members of more general types like numbers? I.e. if I type `1.` to get auto-complete, am I going to see days, and all the rest, as options?? That API design pattern would be a nightmare!

In more modern languages like Kotlin, there is a notion of extension methods and properties, where you would be able to write a library that allows this syntax, but the .days property would only be accessible in files where you have explicitly imported it (so basically a synthetic sugar for a static function call).

How is that a good thing?

> Rails overloads Ruby's core library Time. You're in 1 object the whole time regardless of what you do.

How is that a good thing?

I would have hoped it'd be ready for wider use by now.

https://caniuse.com/temporal

Not exactly. The language doesn't specify whether the value is copied or not and, precisely because values are immutable, there's no way for a user to tell if it was or wasn't.

For example, strings are also immutable value types, but you can be certain that no JS engine is fully copying the entire string every time you assign one to a variable or pass it to a parameter.

[1] https://momentjs.com/docs/#/-project-status/

[2] https://github.com/moment/luxon/discussions/1742#discussionc...

    // A numeric string between 32 and 49 is assumed to be in the 2000s:
    console.log( new Date( "49" ) );
    // Result: Date Fri Jan 01 2049 00:00:00 GMT-0500 (Eastern Standard Time)

    // A numeric string between 33 and 99 is assumed to be in the 1900s:
    console.log( new Date( "99" ) );
    // Result: Date Fri Jan 01 1999 00:00:00 GMT-0500 (Eastern Standard Time)

And a few years later, I'm still using Moment.

And now I'm still using Moment.

And now...

It's simple. In it's simplicity it left many features on the floor. I just can't connect with the idea that someone would need to constantly be on MDN in order to work with it. It's not so horrible that it defies logic.

That seems to be functionality you'd want to have? Or is the intention you convert your numbers to string first and then back to a Temporal.Instant?

And indeed, the static method Instant.from does accept an RFC 9557 string, which requires a 2-digit hour and a time zone offset, but can omit minutes and seconds:

Temporal.Instant.from("2026-01-12T00+08:00")

If you want Date to act like Temporal then only use Date.now() as your starting point. It generates the number of milliseconds since 1 Jan 1970. That means the starting output is a number type in integer form. It does not represent a static value, but rather the distance between now and some universal point in the past, a relationship. Yes, Temporal is a more friendly API, but the primary design goal is to represent time as a relational factor.

Then you can format the Date.now() number it into whatever other format you want.

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

(I can't find the 1.1 docs, but they were the same)

It's one of my favourite examples of how languages pretty much always get date and time hopelessly wrong initially. Java now has one of the best temporal APIs.

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.

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://caniuse.com/temporal

The current global availability of native Temporal is 1.81%. For context, IE11(!) has a higher global usage than Temporal has native support. For my organization, this likely means we're years from being able to use Temporal in production, because getting the polyfills approved is such a hassle.

Keep in mind that even as of December last year, Chrome didn't ship with it yet (i.e. support is less than one month old). Safari still does not.

Checking against version numbers helps cement existing browser monopolies, makes it difficult for new browsers to view websites (even if the browser correctly implements every feature), and encourages everyone to spoof version numbers / browser names which leads to them becoming a less and less useful signal. See any browser’s User-Agent string for an example of this

I mean, the author's conclusion is correct. But I disagree with the rationale. It's like hating an evil dictatorship because they use the wrong font in their propaganda.

  >It wholesale does not understand the concept of daylight savings time

Cheers, great read.

fun demos: https://leeoniya.github.io/uPlot/demos/timezones-dst.html

Implementing such a feature has not only no value, it has negative value. When you program libraries or interfaces you ahould think aboit how people will use it 95% of the time and mane that usecase as simple, predictable and free of potential footguns as possible. This is the opposite of that. It feels like something 15 year old me would have programmed after reading the first book on PHP and not something anybosy with any experience could have thought to be a good thing.

This is not to detract from the quality of the article which is a top-notch introduction to this new API.

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Remember: Date and Temporal objects are logically different things. A Date represents an absolute point in time (a timestamp), while a Temporal object represents a human time (calendar date, clock time, time zone). The fact that Dates are used to represent human time for lack of a better structure is the entire problem statement - the hole that all these other APIs like Temporal try to fill in.

I don't really have a problem with the substance of this blog post. I have a problem with this exaggerated writing style. It means deviating from the fundamental purpose of writing itself!

I had to scroll all the way to the end to find the actual point, and it was underwhelming.

> Unlike Date, the methods we use to interact with a Temporal object result in new Temporal objects, rather than requiring us to use them in the context of a new instance

Bro, just be honest. This entire blog post was totally about developer ergonomics and that's okay. We all hate the way Date works in javascript.

Unless you want your website to run in browsers older than a year

Maybe in 10 years we can start using the shiny new thing?