JavaScript Temporal is coming

Temporal is great. I&#x27;ve been using it for a while in production using a polyfill [1], and it solves all issues I&#x27;ve encountered with the old Date() API (which is a lot).<p>It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that&#x27;s pretty comfortable to use.<p>Yes, it is a bit more complex to handle since it separates time into naive time, instant and zoned time. But by experience, developers only confront complexity when they are forced to, and time _is_ complex.<p>If you want to do the operation &quot;add one day to this timestamp&quot;, you _must_ decide whether that timestamp is local to a specific timezone and which one. Otherwise you&#x27;ll get a bug twice per year due to DST, or when the user switches time zones, or when you deploy on a server with a different timezone.<p>It even solves the serialization issue of the difference between a &quot;fixed-offset&quot; timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe&#x2F;Paris).<p>[1]: <a href="https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;temporal-polyfill" rel="nofollow">https:&#x2F;&#x2F;www.npmjs.com&#x2F;package&#x2F;temporal-polyfill</a>

Man, that took some time to find in the docs:<p><i>Temporal.ZonedDateTime.prototype.withTimeZone()</i> [0], which allows to convert from one timezone to another<p><pre><code> const meetingTime = Temporal.ZonedDateTime.from( &quot;2021-08-01T12:00[America&#x2F;New_York]&quot;, ); const meetingTimeInParis = meetingTime.withTimeZone(&quot;Europe&#x2F;Paris&quot;); console.log(meetingTimeInParis.toString()); &#x2F;&#x2F; 2021-08-01T18:00:00+02:00[Europe&#x2F;Paris] </code></pre> To me, timezone translations as well as durations are such an essential thing which libraries must handle, and it&#x27;s nice to see that Temporal handles both. But it looks like Temporal.Duration doesn&#x27;t offer a custom `format` function, for example `duration.format(&#x27;H\hmm\m&#x27;)` or something like that to format a duration into 1h03m.<p>[0] <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Reference&#x2F;Global_Objects&#x2F;Temporal&#x2F;ZonedDateTime&#x2F;withTimeZone" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Refe...</a>

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, &quot;now get Records and Tuples going too! You can skip that silly Pipe-syntax war if you want!&quot;

Anyone knows how the data about each timezone stays updated within Temporal? Does the TC39 update the data somewhere, then each browser copies that data internally and releases a new version of the browser? If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours?<p>For example Mexico removed DST in 2022 [1]. When using third party libraries like pytz or moment-timezone, you just update the library on your side with the updated data for Mexico. Or bump the language if it&#x27;s handled in the standard library. What about Temporal and my visitors&#x27; browser?<p>[1] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Time_in_Mexico" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Time_in_Mexico</a>

They should add an event to detect when someone changes timezones. That could be another entry in the &quot;falsehoods that programmers believe about time&quot;: programmers believe that your timezone is fixed during usage. But in reality there are millions of people moving between timezones every day.

Very sad that .Now is not a function call. It shouldn&#x27;t be a property.<p>Evaluating .Now multiple times in a loop will yield different values, which is unexpected.<p>C# did the same and it shouldn&#x27;t have been:<p><a href="https:&#x2F;&#x2F;ericlippert.com&#x2F;2014&#x2F;05&#x2F;19&#x2F;when-should-i-write-a-property&#x2F;" rel="nofollow">https:&#x2F;&#x2F;ericlippert.com&#x2F;2014&#x2F;05&#x2F;19&#x2F;when-should-i-write-a-pro...</a>

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words:<p><pre><code> Temporal.Instant.from(&#x27;2020-01-01&#x27;) != Temporal.Instant.from(&#x27;2020-01-01&#x27;) </code></pre> This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I&#x27;m just sad that this wont be possible. Maybe there will be some version that relies on records and tuples, if these ever make it.

Providing comparison functions that work with existing APIs is solid design, should be required reading for any new types added really. Kudos to the designers!<p><pre><code> const durations = [ Temporal.Duration.from({ hours: 1 }), Temporal.Duration.from({ hours: 2 }), Temporal.Duration.from({ hours: 1, minutes: 30 }), Temporal.Duration.from({ hours: 1, minutes: 45 }), ]; durations.sort(Temporal.Duration.compare); console.log(durations.map((d) =&gt; d.toString())); &#x2F;&#x2F; [ &#x27;PT1H&#x27;, &#x27;PT1H30M&#x27;, &#x27;PT1H45M&#x27;, &#x27;PT2H&#x27; ]</code></pre>

I get that the naming Temporal is used for avoiding conflicts with typical time objects like Moment, Datetime, etc. But isn&#x27;t it a terrible name? At first glance I thought it was some kind of garbage collection control

Related. Others?<p><i>JavaScript Temporal Is Coming</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42809834">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42809834</a> - Jan 2025 (18 comments)<p><i>Mozilla: Temporal (Limited Availability)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42776548">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42776548</a> - Jan 2025 (1 comment)<p><i>Is It Time for the JavaScript Temporal API?</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29712118">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=29712118</a> - Dec 2021 (100 comments)<p><i>Temporal: Getting started with JavaScript&#x27;s new date time API</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27661667">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27661667</a> - June 2021 (194 comments)<p><i>JavaScript Temporal</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27395236">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=27395236</a> - June 2021 (1 comment)<p><i>JavaScript Proposal Temporal for Dates is now stage 3</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26432346">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=26432346</a> - March 2021 (1 comment)

From TFA:<p>&gt; When JavaScript was created in 1995, the Date object was copied from Java&#x27;s early, flawed java.util.Date implementation. Java replaced this implementation in 1997, but JavaScript is stuck with the same API for almost 30 years, despite known problems.<p>I&#x27;m not a JavaScript or web developer, and I was surprised by the above. Can anyone comment on why the language was stuck with an inadequate api for so long? What are the forces at work here?

My work does a lot of stuff with time and scheduling, and let me tell you having timezone-unaware date&#x2F;time objects distinct from specific points in time will be so damn useful. The old Date class made it really easy to accidentally screw that up. Third party libraries help, but something as important and fundamental as time really should have a good built-in implementation.

Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? <a href="https:&#x2F;&#x2F;bundlephobia.com&#x2F;package&#x2F;moment@2.30.1" rel="nofollow">https:&#x2F;&#x2F;bundlephobia.com&#x2F;package&#x2F;moment@2.30.1</a>

2024: Nested CSS 2025: Temporal<p>Once we can style &lt;option&gt;&#x27;s HTML&#x2F;CSS&#x2F;ECMA will be complete. Thank you for everyone&#x27;s hard work. Let&#x27;s focus on interop and PWA apis!

This is the most extraordinary thing that I have personally seen in my career as a software developer, and I have worked in many different fields and different languages and on different platforms, but this is by a very wide margin the most exciting.

I used this (via polyfill) for my Typescript implementation of the calendar of the church, and it was fabulous. Using the old Javascript dates I felt like I was always tripping over something... this was actually nicer than Python&#x27;s (already quite good) datetime support.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;grahame&#x2F;church-calendar">https:&#x2F;&#x2F;github.com&#x2F;grahame&#x2F;church-calendar</a>

Carbon is a similar class in the PHP world that&#x27;s inherited from DateTime. This gives a good description of how working with mutable timestamps can cause problems, because methods like $newInstance = $instance-&gt;addDay() modify the original instance and return it, rather than returning a copy that&#x27;s a day later:<p><a href="https:&#x2F;&#x2F;carbon.nesbot.com&#x2F;docs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;carbon.nesbot.com&#x2F;docs&#x2F;</a><p>So it&#x27;s best to mostly use CarbonImmutable so that a new instance is always returned, which works better for higher-order programming style that&#x27;s closer to pure functional programming. I do wish that Carbon was immutable by default, with CarbonMutable as a fallback when necessary, but it&#x27;s too late for them to change it now.<p>I could see a project using use..as statements and&#x2F;or aliases in config&#x2F;app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases like CRBN and CRBNMUT respectively, so that code works as intended without monkey patching or otherwise swapping the classnames and losing code portability.

At first glance, this seems to be in the JodaTime&#x2F;NodaTime&#x2F;Js-Joda tradition of representing different &quot;granularities&quot; of date and time information with distinct types, e.g. with and without timezone information. I&#x27;m not sure if there&#x27;s a formal relationship, since this seems to use different names.<p>I personally like that approach, but I&#x27;m not sure how much sense that makes without static typing. (Maybe TypeScript is established enough that JavaScript APIs are now designed with TypeScript in mind?)<p>From experience with js-joda, there&#x27;s a definitely learning curve compared to moment&#x27;s &quot;one size fits all&quot; type for all things date related. But I found that a lot of stupid mistakes of the kind &quot;a person&#x27;s age is wrong for an hour after midnight during daylight savings time&quot; are prevented by default.

I&#x27;ve used Temporal a bit with a polyfill. It&#x27;s a huge improvement.<p>There&#x27;s no &quot;it&#x27;s coming&quot; really. With build processes and polyfills there&#x27;s no reason to to use it already.

&gt; Java replaced this implementation in 1997<p>I don&#x27;t think it&#x27;s safe to say, more direct comparison of JS&#x27;s Temporal would be java.time[1], which was introduced in Java 1.8 in 2014.<p>[1]: <a href="https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;8&#x2F;docs&#x2F;api&#x2F;java&#x2F;time&#x2F;package-summary.html" rel="nofollow">https:&#x2F;&#x2F;docs.oracle.com&#x2F;javase&#x2F;8&#x2F;docs&#x2F;api&#x2F;java&#x2F;time&#x2F;package-...</a>

This is great. You need to write so much code to do conversion between arbitrary timezones reliably now. And even if you don&#x27;t mind including yet another (large) dependency instead, even those almost all have problems around DST boundaries&#x2F;ambiguous dates as you simply don&#x27;t have access to the timezone rules in the browser right now.

With any new DateTime object in any language I usually look at its persistent fields to judge what the memory and access characteristics are.<p>In case of Temporal it looks like that Chrome goes the JavaScript Date way as it only holds the timestamp:<p>extern class JSTemporalInstant extends JSObject { nanoseconds: BigInt; }<p>And then calendrical fields are computed on the fly. Is this correct?

Long-needed, though I think it&#x27;ll take the ecosystem quite a while to catch up and standardize around it<p>For one: a couple years ago my company migrated from moment to dayjs, which was a huge improvement and carried most of the benefits of Temporal. So even if it were available tomorrow, migration wouldn&#x27;t be a super high priority for us<p>Still a great thing!

Wow, this is great! We were using the proposal library at my job when I first joined, but switched to moment since Temporal seemed frozen. For what it&#x27;s worth, moment is excellent too, but having good datetime support in the standard library is going to be fantastic.

The ECMAScript official docs.<p><a href="https:&#x2F;&#x2F;tc39.es&#x2F;proposal-temporal&#x2F;docs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;tc39.es&#x2F;proposal-temporal&#x2F;docs&#x2F;</a><p>Not the most intuitive name though.

Each time I see a programming language upgrade its base library to improve date&#x2F;time handling, they all look eerily similar to the Java open source library JodaTime, which eventually became JSR-310 (essentially the &quot;2.0&quot; version of JodaTime in the Java base library). Does anyone else notice this? Except for leap seconds, I have never seen a real world business problem that I cannot solve with the current Java date&#x2F;time APIs.

How likely are we to get temporal literals? And in JSON?

Oh wow, I was complaining about working with dates in JavaScript around 2010 or so. It only took 15 years to sort this out.

Cannot wait. That said, somehow I don&#x27;t think it will help us with a UK-based API provider we work with that provide us with ISO-encoded UTC time strings that are actually BST during northern hemisphere summer (or localised strings, e.g. +6 where the datetime component is actually UTC).

I look forward to the day it&#x27;s widely available.<p>But red across the board at <a href="https:&#x2F;&#x2F;caniuse.com&#x2F;temporal" rel="nofollow">https:&#x2F;&#x2F;caniuse.com&#x2F;temporal</a> looks like it&#x27;s still far away, and a 20Kb polyfill seems heavy compared to the 2Kb size of Day.js

If the time zone handling can be added like Golang time package, that would make it very convenient.

&gt; Implementations of the new JavaScript Temporal object are starting to be shipped in experimental releases of browsers.<p>I can&#x27;t get it working with Firefox developer edition or firefox nightly on Fedora Linux. What am I missing here? Can someone please guide me?

Salute to the folks who built momentjs... we used their stuff in prod and it worked like a charm

The name collision with Temporal, the popular durable execution service, is unfortunate.

It’s been 84 years… Jokes aside, congrats to the team! This is huge news for JS.

Sounds great!<p>Just annoyed to use it I have to update all my unit test mocks for Date hahaha...

Relevant XKCD : <a href="https:&#x2F;&#x2F;xkcd.com&#x2F;2867&#x2F;" rel="nofollow">https:&#x2F;&#x2F;xkcd.com&#x2F;2867&#x2F;</a>

Great video covering the API: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;oOK3UzLJ_Cs?si=1MJYtFBmcyJs4tLj" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;oOK3UzLJ_Cs?si=1MJYtFBmcyJs4tLj</a>

I&#x27;ve been waiting this &quot;moment&quot; for a long time...

I&#x27;m honestly really excited for this to be more widely adopted to the point it can be used without polyfills. While the API is a little verbose for my liking, it&#x27;s extremely capable.<p>Being able to replace all the various date and time libraries with something browser-native is a massive win for bundle sizes, as even the most lightweight ones are going to start creeping up there once you&#x27;re dealing with localisation on top of it.

It’s almost a shame, considering all the effort that went into Moment and Luxon, which will largely be superseded. Luxon especially is a joy to work with.

Will this finally have a proper datetime formatter, too?

<a href="https:&#x2F;&#x2F;caniuse.com&#x2F;?search=temporal" rel="nofollow">https:&#x2F;&#x2F;caniuse.com&#x2F;?search=temporal</a>

Is there something similar for Python? I only write the occasional script, and the default time functions are just bad.

This looks great, and I&#x27;m getting jealous. Every language should have something like this in its stdlib.

Curious to see how Temporal works with JS on the client side!<p>It’s an awesome tool for durable execution, I’ve been using it in my OSS projects, and it has been instrumental in building a leading Reverse ETL platform powered by Temporal.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;Multiwoven&#x2F;multiwoven">https:&#x2F;&#x2F;github.com&#x2F;Multiwoven&#x2F;multiwoven</a>

Handling dates is an archetypal engineering and logic puzzle to evaluate programmers.

Coming but only available in one browser or run time, and then with a feature flag.

I’ve used date libraries from several languages and they’re all pretty awkward, but Ruby seems to have a very elegant solution thanks to the fact that primitives are also objects, so for example you can write things like 1.minute.ago or 1.day.from.now, which really helps in quick code comprehension.

I have one question: why ˋTemporal`? That looks weird to me. Why now `Time`?

JavaScript never supported support time zones is news to me

I was really confused for a minute, I thought this was referring to the Uber spinoff durable execution framework <a href="https:&#x2F;&#x2F;temporal.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;temporal.io&#x2F;</a>

It feels like temporal has been coming for 15 years.

Thought this was about <a href="https:&#x2F;&#x2F;temporal.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;temporal.io&#x2F;</a> ...

wrote the whole `internationalization` instead of `i18n`. definitely not a developer.

Umm..I am not sure how the Islamic&#x2F;Hijri calendar gonna work. Tomorrow is the first Shabaan in Pakistan but it is still 30th Rajab in Saudia. How will JS figure this difference out?

Awesome. Can’t wait

Great Mozilla!

Finally!

&gt; working with dates and times in JavaScript will be hugely simplified<p>&gt; To help you get up to speed, there are over 270 pages of Temporal docs on MDN<p>Not that I&#x27;m complaining about extensive documentation, but seeing these two lines juxtaposed doesn&#x27;t inspire much confidence.

Why aren’t time zones enums and instead still text strings?

270 pages of documentation -- wonderful! &#x2F;s

I was very confused why Mozilla was shilling for temporal.io

I might be mistaken but I think Hatchet.dev is a good Typescript alternative to Temporal

Can someone who&#x27;s been following this explain why they&#x27;re designing a new API instead of merging one of the successful open source APIs into the standard?

This is the first javascript change in a decade that actually seems like an improvement for web pages (and not just web applications). Nice.

Holy fuck. This has some seriously fucked up syntax, function names and the like. Ugliest shit I&#x27;ve ever seen.

The vast majority of websites should be calculating dates in a server and merely presenting them to clients.<p>I have wondered why there isn’t a span style element which takes a UTC timestamp and presents it to the user in their preferred time zone. I even wonder if it could be done in private way so that JS cannot even access the value (made more difficult by layout and size).<p>Similarly a form element for date times could simply return the UTC from the local choice.<p>I am just wondering out loud and not an expert.

Just want to chime in as someone who from time-to-time (heh) has to deal with datetime-related things and say, I hope for nuclear annihilation upon all clocks and other miscellaneous time-telling instruments, and most of all to whomever it is the world over that decides that, no, we&#x27;re special and don&#x27;t need to follow any kind of logic for our timezones (looking at you, China but also basically everyone else in the world).<p>With that out of the way, very excited for Temporal and am very thankful to the people doing this hard work!

Future generations will no doubt remember this announcement as a revolutionary leap into a brighter future. But I&#x27;m sure I&#x27;ll still be using Moment.js ten years from now the way I&#x27;m still using JQuery 3.x now.<p>Javascript is all we have for front end web apps now, impoverished as it is as a language. But excuse me if I don&#x27;t get excited every time a proposal is rolled out to bring it close to the 21st century.