JavaScript Temporal is coming

A few weeks before the time change that happened last fall, I had to debug an issue in our production environment related to something that got scheduled at, IIRC, 1:30 am "local time" and due to some date-handling code that didn't handle the time shift properly, I was getting "ambiguous time" errors. Anyway, I fixed the issue and in the process became intrigued by the interesting fact that there are certain times each year that happen twice.

A couple of weeks after that, on the night of the time change, I went to a party and afterwards a friend of mine and I went back to my house and started jamming and messing around with synthesizers and so on. As it neared 2:00 am, he told me he'd best be heading home, because it was getting rather late. I told him not to worry and that we were about to travel back in time...which we did. Then we spent another hour hanging out until it was almost 2:00 am again and he left.

I don't ever recall actually witnessing this happening before, in the past, I've always awakened in the morning to find I needed to change the clock on the stove. I really recommend staying up for the time change, because this is a pretty magical time of year. If you don't like the hour you experienced between 1:00 am and 2:00 am, you have just one opportunity per year where guess what — you get a do-over! Or if you really loved it, guess what - you can relive it!

That won't save you everywhere, Greenland falls back at midnight (12 AM Sunday to 11 PM Saturday) in order to synchronize their DST change with Europe

https://www.timeanddate.com/time/change/greenland/nuuk

A long while ago my friend and I released a Safari extension that shows a few clocks in the timezones that you choose. I can't recall the details, but we had an off by 1 error on a few zones during DST.

I ended up fixing it by hand changing the time, releasing a version every 6 months for years, otherwise we would get mails about it from the few users using it.

I think I could automate this or otherwise solve the issue, but it always felt nice to move the clocks of a few hundred people.

Are your production servers configured in something other than UTC, or is there a factor here I'm missing? I've never really seen a good reason for a live server not to be Z'd out

Java.time basically is based on joda time and aside from slightly different package names is largely the same thing. That happened to more parts of the Java API. The concurrent package also started out as a standalone library.

Joda time has inspired spinoffs on lots of platforms. Including js-joda for the javascript ecosystem. I'm not sure how much the new Temporal approach is based on that but it wouldn't surprise me that that was one of the starting points for the new standard.

+02:00 is not political. It's an offset from UTC and will be the same offset in the past and future.

Europe/Paris is political. It defines that offsets change at certain times of the year, but that could change tomorrow, or the political boundary that the timezone applies to could split such that the person or entity needing a time in their "local" timezone finds another one needs to be picked (see various US states/counties applying/disapplying daylight savings).

It's impossible to be 100% confident what the offset from UTC will be at any time in the future. You also need to be a historian to correctly apply it to times in the past - take https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan... as an example!

The issue is that if you have a timestamp (e.g., `2025-06-20T17:00:00+02:00`) and a time zone (e.g., `Europe/Paris`) and you go to serialize it, are you explicitly including the time zone in that serialization? And when you deserialize it, are you checking that the offset is still valid for that time zone at that time?

Temporal fixes this by using RFC 9557[1], which includes the time zone in the serialized representation. RFC 9557 is a superset of RFC 3339. So where as previously you might just emit `2025-06-20T17:00:00+02:00`, using RFC 9557, you would emit `2025-06-20T17:00:00+02:00[Europe/Paris]`. For example, using Temporal:

    >> instant = Temporal.Instant.from('2025-06-20T17:00:00+02')
    >> zdt = instant.toZonedDateTimeISO("Europe/Paris")
    >> zdt.toJSON()
    "2025-06-20T17:00:00+02:00[Europe/Paris]"

You can read more about this at https://tc39.es/proposal-temporal/docs/zoneddatetime.html and search for "conflict". There's an example about Brazil abolishing DST in 2019 that should lay it out for you.

Separately from even this, there are other concerns. If you forget to include the time zone in your serialization and then just deserialize it as a simple timestamp, then it makes it very easy for arithmetic on that value to be wrong because it won't be DST safe (unless you're careful to reconstitute its time zone somehow). With Temporal and RFC 9557, all of that is handled for you automatically.

[1]: https://datatracker.ietf.org/doc/rfc9557/

Places like Europe/Paris or America/Los Angeles can participate in daylight savings, and if they do, they may have different schedules, and those schedules may change at different points in history due to the passing of laws. Europe and the us already have a different schedule for daylight savings, and the whole west coast is trying to opt into permanent daylight savings for the last several years. But that would require an act of congress.

Programmatically it mostly means you have to ship metadata about how the offsets change over time, which needs to be updated periodically. Browsers already ship that metadata, so it is really nice to finally have a way to access it from JavaScript without shipping the extra few tens of kilobytes.

Europe/Paris might change between now and the referenced time.

One represents a time in a specific place, and one represents merely a shift from UTC. A specific time zone can have different offsets depending on the time of year, for example with Daylight Savings Time.

And lived on a flat planet.

if only it was as simply a reading int64 epoch values :')

Just add "What Three Words" for time.

And time since epoch was defined sanely.

Agreed this sounds like they are looking for Intl.DurationFormatter.

Temporal.Duration.prototype.toLocaleString will end up using Intl.DurationFormatter though, so that will ultimately be what he wants (probably going to depend on that ICU4X implementation being complete though).

DurationFormat looks cool but it didn’t behave as I expected.

https://github.com/tc39/proposal-intl-duration-format/issues...

That's a bummer. I wish there was a way to use non primitive objects in Maps & Sets more effectively then. Perhaps a well known Symbol for hashCode or something.

BigInt shipped because financial organizations needed it for certain applications.

To be honest, this reads kind of insane, and reminds me of how wasm was at least partially designed around V8 idiosyncrasies and limitations.

Pattern matching (and expression based assignment, of which idk if there’s a proposal for or not) are two things that would really drive a ton of value.

I also REALLY want records and tuples.

We’ve had Map with those semantics since 2014, came out in Chrome a few months before Set.

Record/Tuple objects are immutable primitives with structural equality, not object reference equality. So little relation to AS3 Dictionary/ES6 Map, besides being possible keys for Map/Set.

> We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

I strongly disagree, it's never been easier and more pleasant to write modern JS without transpilers. I've only rarely had to reach for a framework or transpiler in the last few years.

Come now, this is silly. There are plenty of us that are explicitly avoiding build phases because, for us, what needs to be built adds very little benefit.

Working with assembly is comparatively expert work that few professionals are good at. JavaScript can be written by kids.

The main reason people don't write much vanilla JS is because they're writing TypeScript instead.

> Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

…Huh? Are you referring to transpilation?

are there polyfills for those proposals?

Yes, the user's operating system probably already has an IANA database somewhere, or the browser could bundle its own IANA database.

And the browser probably already has some way to access that database anyway.

Please don't forget about us node users (and deno and bun I guess, too).

Windows has its own complex in different ways system-wide Time Zone Database, but these days also has a full IANA Time Zone Database compatibility layer.

I don't believe adding this event would represent a new data point for fingerprinting because it's already possible to detect timezone changes by polling `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`.

First JavaScript is unfortunately not just for web apps. It’s also for desktop apps.

Say my normal work day is from 8-5 and I work in the Eastern time zone. I set my Slack DND to outside those hours.

I hop on a plane and go somewhere on the west coast. The perfect case, Slack would notify me of the change and let me decide whether I wanted to adjust the DND to local time or keep it.

There are two possible scenarios for me. I could have flown to Seattle for a business meeting and I want to change my DND to local time to be in sync with the rest of the team onsite.

The other scenario is that I’m flying to Los Angeles to hang out. But I’m working during the day and I still need to work east code time.

To my understanding, it shouldn't require that much effort since browsers should already be keeping track of timezone changes, see Chromium's time_zone_monitor [0]. Browsers could emit a "timezonechange" event on the window.

A quick search of gecko-dev shows entries for both WM_TIMECHANGE and NSSystemTimeZoneDidChangeNotification, although they haven't separated it into its own service. I imagine they also track timezone changes for other platforms.

[0] https://source.chromium.org/chromium/chromium/src/+/main:ser...

So that you can update the UI to show the new time zone? Or change the time format to indicate that it’s no longer in the same time zone as the user is in? That’s just off the top of my head, I’m sure there’s more.

Sending emails at specific user times, billing (be careful with this one!), scheduling events in the future, reporting it to other users (Microsoft Teams' "it's 20:39 in this user's Timezone").

I would expect a timezonechange event to get emitted on the window and that the developer would be responsible for handling it accordingly. This wouldn't require any changes to Temporal.

Iss uses Coordinated Universal Time which is just GMT.

Wouldn't you be in the time zone you are traveling over, the same as with other modes of transportation?

I.i.r.c. ISS uses UTC

That only works for past events, not future ones. Converting to UTC is lossy so rendering timestamps correctly in the future becomes problematic with DST/TZ rule changes.

> and render instantaneously in current time zone

And for that you need to have a timezone-change event, if you don't want to poll the current system timezone.

For timestamps, which are considered fixed points in time, yeah. Dates and times are different. If you block off 12-1pm for lunch in your calendar every day, the actual timestamp of that event might change if you fly elsewhere and set it to use the local timezone automatically. Same with holidays and birthdays.

The operating system is responsible for tracking timezone changes. If you turn off automatic timezone switching or you're in an airplane without internet then the timezone change just won't be detected, which is perfectly fine. That isn't an argument against supporting a timezonechange event.

Every major operating system has had a way to keep track of timezone changes going back over 25 years. This was during the era where most people were on desktops, but now most people are on mobile devices so it's more relevant than ever. Chromium already has a time_zone_monitor service in place, which I linked in a different reply.

Currently, if you want to detect that the timezone has changed you have to poll `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`. An event would just let you get notified without requiring polling.

Updating the displayed time on the client is precisely one of the reasons that this feature can be desirable.

> someone reading a log will want server time or UTC

I personally prefer local times when reading logs, but I'll absolutely take UTC over a wrong local time.

Yeah, that's one of the core problems, there's no overloading of equals in JS and no other cases of objects using non-reference equality. Adding that in itself would be a big deal (ex. see the Records and Tuples proposal which has been going on for years and may never complete)

There's exactly one IIRC. document.all

Passing Dates to a React component caused re-rendering issues in some of my applications due to Date being an object.

I had to resort to numbers (Unix time) to not have to add memoization everywhere. Seems like this will continue with Temporal. Or React-Compiler will solve this.

There is the record and tuple proposal. If we'd have methods on records (currently not part of the spec) this would be trivial.

I wouldn’t call this a particularly crazy hack, it’s also called string interning and I reckon that’s what every language runtime does when strings are immutable (which includes javascript runtimes, also this isn’t required by the language specification).

Temporal includes `equals` methods on every type. String comparison sometimes works, but there are enough cases where it doesn't (especially when comparing strings that refer to the same data but were generated by different libraries so formatting is different for things like trailing zeroes of decimals, time zone aliases, etc.) that it's usually best to use a library function for comparison instead of just using string comparison.

I don't think you create Temporals though. It's essentially a namespace for things like Instant, so it need not be a noun.

Time has the opposite problem. I expect it to be a class, not a namespace. Time.Time creates more confusion, not less.

Boolean is also a built in named after an adjective, and we deal with it just fine :)

Temporal is not "odd", it's just a bit less common in english that many people are used to

> during the IE5/IE6 era

During that era was a peak of browser innovation. IE5 and IE6 contributed a lot of things to web standards. They contributed a bunch of things that web standards eventually rejected too, but that was the risk of innovation at the time.

It was the period between IE6's last feature update and IE7's first release where Microsoft declared the browser wars "finished" and disbanded the IE team entirely that was the Darkest Age. So about 2001-2006 were the darkest few years.

It certainly had repercussions until around 2010, but the worst "sabotages" were done and gone by then. "Legacy" problems.

Microsoft was MASSIVELY trying to make web applications a thing. They introduced HTML Applications[1] in 1999 (e.g. Electron). In 2001, they added the JavaScript features that let us have Gmail and Google Maps (XMLHttpRequest). They let you rebuild your Windows desktop or any folder as a HTML in Windows 2000/ME. They created a ton of APIs from web components[2] to CSS effects[3] in 1998.

However, when Netscape died, Microsoft did a 180 and went from the leader in promoting the web to the absolute worst obstruction. It seemed like they completely de-funded their IE development team.

[1] https://en.wikipedia.org/wiki/HTML_Application

[2] https://en.wikipedia.org/wiki/HTML_Components

[3] https://learn.microsoft.com/en-us/previous-versions/ms530752... (previously was just filter:)

> Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share.

Boy, it's a different company doing this now, but this is definitely still something that is happening, especially in mobile.

Is Java not designed by committee?

And for the longest time, nobody even considered javascript to be a serious tool; It was rare for anyone to write more than a hundred lines of javascript.

I remember when google introduced gmail in 2004. Suddenly google had done full single-page application in javascript, proving that not only was it possible, but that the resulting user-experience was awesome.

At the time, there were no javascript frameworks. Jquery (if you can even call it a framework) wasn't created until 2006. I don't think there were even helper libraries.

I mostly remember javascript from dynamicdrive.com, where you would go to find quick snippets of "Dynamic HTML" to copy/paste into your html. Sometimes there were useful things like roll-over menus, but I remember many of them being silly toys, like sparkles that would follow your mouse around the screen, or snow which would slowly cover the page.

1997 would be JDK 1.1, which introduced the java.util.Calendar/GregorianCalendar classes. The Calendar API was an improvement in some use cases over Date, but it's biggest flaw was mutability. The current API is based on JodaTime and is very similar to Temporal.

and yet on threads about Elixir there seems a lot of people who care – rightly so, immutability it's great and Elixir makes the best out of it. Don't give up the good fight!

Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.

That's fair, but they didn't need to - just make a new Date library and deprecate the old one.

C uses zero-based array indexing. A C array variable is a pointer to its first element, and an element index is just an offset from that. Element 0 is at start + 0, element 1 is at start + (1 * element size) etc.

Which why the fields of the 'tm' structure [1] (used to represent dates and times) are zero based§. Makes it easy to index into eg an array of day names using tm_wday. I guess at one time Java.util.Date was a leaky abstraction layer on-top of such an api.

§ Except for the tm_mday element, which curiously is 1-based. I've always assumed that this is because it is unlikely to be used as an array index. A long time ago I'm ashamed to admit that I used tm_mday == 0 as a quick check for an invalid tm value.

[1] https://en.cppreference.com/w/c/chrono/tm

Just spitballing, but in C it was always the convention to use zero-based indexing. Probably because you were often adding these indexes to pointers (literal memory addresses) to index into an array, so you needed a zero to index into the first slot of the array.