Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot).
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's pretty comfortable to use.
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.
If you want to do the operation "add one day to this timestamp", you _must_ decide whether that timestamp is local to a specific timezone and which one. Otherwise you'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.
It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris).
I actually don't think Temporal takes a ton of inspiration from the `chrono` crate personally. I think it's definitely more from Joda (as you mentioned) or `java.time` these days, and some of the other Javascript datetime libraries that have cropped up over the years (thinking about date-fns and Moment.js).
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!
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
This is grand-parent's point IMO: running your cron on UTC is a decision to have it on that specific timezone.
So you're effectively deciding for instance to send your user newsletter at varying hours, sometimes at 1h00, sometimes at 3h00. Or accept that every scheduled event needs to be appropriately timezoned and adjusted as needed if DST change.
Or to have your logs timestamp be non obvious when comparing events separated by months, or have to convert all your business timestamps to a different timezone.
Those are all sensitive decisions, and we usually accept the trade-off, but it needs to be an explicit tradeoff.
This is true, but there's one fly in the ointment I noticed: a lot of people _hate_ using time zones that refer to a real life location.
They ain't gonna bother finding out whether "Europe/Paris" is like a wide slice of France or just specifically Paris, they don't want to tell you they live in Paris and will get annoyed.
When using things to like, schedule online community events or whatever, this has been a pain. People _want_ to use fixed offset, they are fine with things like "CET/CEST", and _hate_ things like "Europe/yourexactcoordinates."
And before you run into here, _I_ know time zones well enough to be chill - most of them (all?) are actually really large areas. But there's plenty of people who are both privacy-minded and not really interested in researching the differences between a "time" and a "time zone" or whatever because they aren't terminal dorks.
Those are from different time epochs, by the time Rust 1.0 was released, Java already had this approach implemented in standard library via java.time and didn't need any 3rd party libraries for this.
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.
> It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris).
+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!
Even countries that are on UTC don't save you from this. I had no idea until very recently but there is a time that simply never existed in Iceland!
Wednesday January 2st 1908 00:00 clocks were turned forward 28 minutes to 00:28. So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round and one might think they are the best and easiest country to handle timezone wise.
I should point out that UTC didn't begin until 1960...
The 28 minutes jump is likely Iceland coming into alignment with GMT, for much the same reasons as Ireland did; to improve trade and commerce in a world now using telegraphs, telephones and trains. We're ok becoming disconnected from mean solar time in order to connect more with each other.
Samoa skipped a day in 2011, jumping from UTC−11:00 to UTC+13:00, so that it could align with Australia and New Zealand, its biggest trading partners -- so Australia's Friday is also Samoa's Friday.
We'll always have discontinuities in civil timekeeping, as it's there to serve the whims of humans, not the other way around.
In the same way that an hour is skipped in many places at the beginning of Daylight Saving Time every year (and the offset changes, e.g. from UTC–5 to UTC–4),
on this particular instant, in Iceland, 28 minutes were skipped because Iceland changed from the offset of Reykjavik’s mean solar time, rounded to the nearest minute (UTC–1:28) to the offset of Reykjavik’s mean solar time, rounded to the nearest hour (UTC–1).
So only from that moment on, Iceland was using UTC–1.
That but also and for me more importantly it does not tell you how to add time - If you add one month of hours to a date in October, it depends on the timezone whether you will end up one hour of local time earlier or not (due to DST), because then +02:00 might be +01:00
While this is true, most often if you want to do "now plus a month" you'll mean "at the same time on the local clock", and disregarding timezone changes, while most often if you want to do "now plus four hours" you'd actually mean four real hours, and you want to calculate in the DST changes to make sure you have four actual hours in your duration
Adding 1 day still works the same with respect to civil time but the offset is wrong since it doesn't account for the DST change. And adding 24 hours leads to a different result as well. This is one of the reasons why RFC 9557 is so important for serializing zoned datetimes when you want your arithmetic to be DST safe. Previously, to get this right, you had to include a time zone out of band somehow along with your RFC 3339 timestamp.
It's a really well thought out RFC: the offset, the civil time zone name, and a flag for whether that civil time zone is critical information can all be stored, and an inconsistency marked critical MUST be acted upon by the application explicitly, either by rejecting or requesting user interaction.
This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I honor the absolute point in time, or do I honor the notion of 5pm?"
Unfortunately, there's going to be a lot of chaos if this happens. Systems like Postgres only store the absolute point in time, normalized to UTC, despite what the name "timestamp with time zone" might imply; an application team or DBA making a decision about this might need to look at other domain-specific metadata e.g. the physical location of the associated asset to determine whether to add or remove an hour. I shudder to think about what this might imply for e.g. HIPAA protected medical systems; the impact of the ensuing bugs might be measured in lives.
Yeah the PostgreSQL situation is just utterly appalling. The fact that there is a type called "timestamp with time zone," that specifically calls out the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown.
> This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I honor the absolute point in time, or do I honor the notion of 5pm?"
Yeah! It's great that Temporal rejects by default, but does let you override that and choose whether to respect the instant or respect to the civil time. And it lets you do that with a high level configuration knob. You don't have to code up the logic yourself.
I agree, but I believe Postgres is just following the SQL standard here?
What's even crazier is that writing plain TIMESTAMP gets you TIMESTAMP WITHOUT TIME ZONE, as is also mandated by the standard (the Postgres docs call this one out specifically). And that behaviour can be summarized as: not only don't store the timezone, but also ignore the timezone you get given.
For example, I'm on GMT/UTC right now, and I see this:
select '2025-01-30T12:00:00-0800'::timestamp with time zone; -- 2025-01-30 20:00:00+00
select '2025-01-30T12:00:00-0800'::timestamp; -- 2025-01-30 12:00:00
There are many valid and justifiable reasons to do crazy things. But it's still crazy. :-)
I don't think that completely absolves PostgreSQL though. It seems like they could add things to improve the situation and de-emphasize the use of TIMESTAMP and TIMESTAMP WITH TIME ZONE. But I am not a database or PostgreSQL expert, and there are assuredly trade-offs with doing this.
But yes, absolutely, the fact that TIMESTAMP is not just a timestamp without a time zone, but is actually a civil time is also equal parts crazytown. Like, a timestamp is 100% an instant in time. It is physical time. A number of seconds since an epoch. But PostreSQL (or the SQL standard) interprets it as a civil time? It's ludicrous and has assuredly confused countless humans. Especially those among us who don't know enough to question that PostgreSQL (or the SQL standard) might have gotten it wrong in the first place.
>the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown.
It's always seemed reasonable to me. Sure, "TIMESTAMP WITH UTC OFFSET" would be even clearer -- but, as has been pointed out already, there are 2 valid ways you might want to handle time addition/subtraction, and only one of those ways enables addition to be done without pure speculation on what decisions will be made by political entities in the future, and PostgreSQL does it that way.
But I'm not critizing the behavior. I'm critizing the name.
And it's not even a timestamp with a UTC offset! It's just a Unix timestamp.
If you think the current naming is "reasonable," then we are likely living in two different planes of existence. And no amount of back-and-forth over the Internet is going to help. This is a level of dissonance that requires an in-person discussion in the pub to resolve.
I wonder what happens when a timezone ceases to exist, e.g. what if Paris is renamed to New New York after the British take revenge and take over France.
Your example of “New X” is spot on, because there was a timezone with that name, “US/Pacific-New”, which was different than “US/Pacific”. Bit of history: it was added to some timezone libraries because there was a bill in congress to add it, but it never passed. I had to fix a bug because users were getting set with that timezone and then other systems/libraries were barfing on it…
A timezone changing or being eliminated doesn’t erase the history of that timezone. So you can still use the last definition of such a timezone if the date is still in the future, or use the appropriate definition of the timezone at the time of a date marked in the past.
> you can still use the last definition of such a timezone if the date is still in the future
but that'll possibly give you an incorrect time!
If you want to store "8am in Paris on the 2026-01-01", then you store "2026-01-01T08:00:00 Europe/Paris". Great, if Paris decides to change their offset rules, that's fine.
Currently, that would be `2026-01-01T08:00:00+01:00` but if Paris decide to ditch DST, it could become `2026-01-01T08:00:00+00:00`. All good, you stored a timezone rather than an offset, so you're decoupled from the timezone->offset changes.
But if tomorrow `Europe/Paris` cease to exist, and is replaced with Europe/NewNewYork? The last definition of Europe/Paris would make this date `2026-01-01T08:00:00+01:00`, but if Europe/NewNewYork ditched DST then it wouldn't be 8am for the people living there, it'd be 7am.
You're decoupled from the timezone->offset changes, but not from location->timezone changes.
The reason the zones use city names is because city identity is far more stable than national or regional borders. Still, the system can gracefully handle deprecation of a zone name. If Paris is renamed NewNewYork by edict of some new global despot, the IANA will just alias the two names together.
Hopefully the British would be kind enough to email the TZ DB group at the IANA (tz@iana.org) a couple years in advance of the legislation to change the name so that the group can get started on collecting the DST rules for Europe/NewNewYork. Some people and devices will probably stick to Europe/Paris out of habit and/or resistance to the change, so the TZ DB would probably be unlikely to remove it, but they may point references from it to Europe/NewNewYork as the new "canonical" name. Plenty of the DB entries are just pointers to other entries already today, for one instance it was decided that America/City and Europe/City maybe is too conflicted a namespace and we see increasingly more "the canonical name is America/State/City" or "the canonical name is Europe/Country/City".
As a Canadian, I would love for my timezone to be Americas/Toronto or Americas/Canada/Toronto rather than America/Toronto, but that's pretty far down my register of first world problems.
I'd also like all 50 state capitols (and possibly also their largest city) to exist as E.G.
Sol3/US/WA-Olympia and Sol3/US/WA-Seattle (respectively to the above; I don't know Canadian provinces that well)
Sol3 is a prefix for the 3rd planet (starting ordinal 1, but anything in the orbit of Sol can be Sol0) in our solar system. It's also nicely short so easy to type out in command lines.
Every state _should_ have it's own TZ file, even if it's just an alias. That's a good forward compatible way of allowing the same config to work if future legislative efforts produce or remove timezones. It would also allow E.G. Arizona's non DST timezone to remain correctly configured in some future where the US finally ends the nightmare of DST forever.
Including the state would be odd for the exact reason you demonstrate; a lot of people outside the country don’t know or care, especially with capital cities — who knows what region Ottawa or Canberra are in?
Country largely just makes sense to disambiguate cases like the two different cities a few hundred km apart both named Vancouver.
For US cities it would make sense, though the very largest could be argued to also not include that.
Use case: Configure device for customer in another state, OK like the mailing address state 2 letter code is XX what city? Oh there's a choice of two. The one I've heard of is probably the biggest city. Either way, it comes out OK.
What if you don't know what state something is in? Sol3/US/*City should shell expand on command lines.
The prefered canonical name is continent-or-ocean/city-or-small-island because continents and cities are more stable than countries and country names. The America/state/city convention is the exception, not the rule.
Some timezone identifiers have changed, e.g. Asia/Calcutta to Asia/Kolkata in 2008 and Europe/Kiev to Europe/Kyiv in 2022. But the TZ DB maintainers are rather reluctant to make such changes, and require “long-time widespread use of the new city name” in English before deciding so.
https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen
> https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen
Thanks! I was the co-champion of that proposal. Parts of it were merged into Temporal last year, and other parts are already part of the JS Internationalization (ECMA-402) specification here: https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database
What if England and Germany fight for France, half the country being occupied by Germany using `Europe/Francefurt` and the other half by England using `Europe/NewNewYork`? Then you can't know for sure how to interpret a "Europe/Paris" date without knowing the exact geographical location
If I understand [1] correctly, two new zones (or one new one and the old one) would be created in that case. E.g. if Strasbourg would be occupied by Germany in 2027, a new Europe/Strasbourg could be created which has the same rules as Europe/Paris until 2026, and the rules of Europe/Berlin as of 2027.
> On 29 March 2014, after annexation by Russia, Crimea switched from Eastern European Time (UTC+02:00) to Moscow Time (UTC+04:00 then, subsequently changed to UTC+03:00). [2]
Crimea has its own zone in the IANA database, Europe/Simferopol, which was updated in 2014 (and already existed before, as it already used Moscow time from 1994 to 1997). [3]
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:
And when you go to deserialize an RFC 9557 timestamp, Temporal will do some validation to help ensure it's still correct. For example, you might serialize a RFC 9557 timestamp that is in the future, but at some later point, that region might abolish DST. At which point, your RFC 9557 timestamp might or might not resolve to the intended time. If it was in DST, Temporal will reject it at parsing time.
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.
I get that it’s more correct, but it assumes that Europe/Paris is a constant representation of how to apply the timezone-specific stuff but that’s incorrect. For example, ‘2025-06-20T17:00:00+02[Europe/Dublin]’ is a very different time if it’s created today vs if it were created in 1760 [1]. That’s a very extreme example, but timezone rules change and dates created from before the change was announced would be interpreted differently from ones created after they were announced. It’s interesting to me the standard doesn’t embed the creation time of the timestamp in UTC as well.
It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets.
That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened.
All of this is kept track of in the IANA Time Zone database, and labels like `Europe/Paris` are from keys into that database, not arbitrary. https://www.iana.org/time-zones
Sometimes when jurisdictions do weird stuff like changing their rules for (say) when Daylight Savings starts with no notice (effective tomorrow!), the libraries can take a bit of time to catch up and be correct again (and have the new version be distributed to all users).
But keeping track of (say) that America/New York on March 25 2024 is UTC-4 but March 2025 1990 is UTC-5 hours (they changed when Daylight Savings started in between those years) is absolutely something current (eg OS) time libraries do.
As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already!
That's why you say "Europe/Paris" or "America/New York" instead of "UTC-5", to let the library figure out the rules for offsets at that location on the time specified.
I assume Temporal will do the same. JS environments are usually running on OS's that will already provide this service, the browser or other execution environment won't have to implement it from scratch. Although I think moment.js did it from scratch, and distributes a timezone database with moment.js packages.
> As well as keeping track of the gregorian correction in (depending on country) October 1582 (skipping over 10 days in the calendar!), when calculating historical intervals. They really do this, already!
Which libraries do this? Libraries usually implement proleptic calendars, including Temporal[1], which specifically do not account for shifts like this. And indeed, the Temporal docs even call out this specific example.
Ruby date/time handling is confusing, with too many overlapping classes, developed at different times with odd interfaces and/or semantic edge cases (not unusual on other platforms either), but I believe the things people use as default/recommended standard these days on ruby actually do support gregorian/julian changeover!
> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened.
It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city.
You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose.
If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited.
For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time.
Location-based tz's are the best we can do right now but even still they have intractable problems when things change.
Yep. That said, for end users it's a fairly good story because consumer OSs have gotten very good at automatically adjusting clients' time zone based on geo-location. Just like when you fly to another country and the first thing that happens when you connect your laptop to the internet is you're offered to change your time zone to the local time zone. I assume that the same thing happens when you're in a place whose IANA time zone changes like your America/Punta_Arenas case or many others like it.
On re-read, I understand the other aspects of what you mean better. True!
For dates in the past it isn't much of a problem. `America/[city in chile]` in the past (created before the change, refering to times before the change) still has a specific point-in-time meaning even when things change.
The problem is dates records created in the past but referring to times in the future. Which could now be ambiguous or wrong... and this is the first time I'm thinking about it, I'm not sure how easy it is to detect, I guess it should be detectable which dates may be ambiguous/wrong if you know the date of their creation (before the change was known), but it would take caring to write guards about it and having access to databases with sufficient info.
> For dates in the past it isn't much of a problem. `America/[city in chile]` in the past (created before the change, refering to times before the change) still has a specific point-in-time meaning even when things change.
Right - date-times in the past are always easy (at least until you have to take relativity into account). An event happened at some instant in the universe and you just need an agreed upon representation of that instant. UTC works fine for this - record the UTC-based instant at which the event happened and you can always translate it into any other representation without losing information. Recording it in your local timezone is fine too, as long as you also record the UTC offset or timezone along with the instant.
> I guess it should be detectable which dates may be ambiguous/wrong if you know the date of their creation (before the change was known)
Yeah - in theory, when a timezone is added, you could probably link it to timezones that users of the new timezone might have previously used. And then any future times that were saved using that timezone, you ask someone if they are still correct or if the timezone needs to be adjusted to the new one
For example, if a new timezone was added for southeast Colorado, you might ask someone about all times scheduled in both the Denver & Phoenix timezones, because you don't know which one people might have picked.
It gets complicated though because you need to keep track of which entries have been double checked and which ones haven't, and you need to keep track of the version of tzdb that you reconciled against, because there could be another change in the future.
Right, I mean that if in 2030 for some odd reason half of Punta Arenas does DST and half does not, then 'America/Punta_Arenas' would not work as a timezone designator anymore! Obviously unlikely, I probably should not have mentioned it.
Can you provide a concrete example? Ideally using Temporal to show where it's going wrong. Like, if you created `2025-06-20T17:00:00+02[Europe/Dublin]` (the instant) in 1760, then its civil representation would be different, to account for the rules in place at the time. And then if you went to deserialize it today, Temporal would reject it. You'd get an error, because the rules in place when the string was serialized don't match the rules in place today for that instant.
To be clear, I might be misunderstanding what you're saying. So that's why I'm asking for a concrete example. That will cut through everything. And if you didn't, I would strongly suggest you take a look at https://tc39.es/proposal-temporal/docs/zoneddatetime.html and search for "conflict". I think that will help explain things.
> I get that it’s more correct
We can chase perfection, but perfection isn't the goal. All models are wrong, but some are useful. In other words, the question isn't whether Temporal's model of interaction with time is wrong (it is!), it's how wrong it is and what its impact is that matters.
I must be misunderstanding what you’re saying. How does Temporal know to reject something serialized from before a rule was changed when the creation time of the serialized representation isn’t encoded? You’re saying in 1760 [Europe/Dublin] would be a different string vs today? A more concrete example is normal time-zone rule changes - `2025-06-20T17:00:00+02[Europe/Dublin]` would represent different instants if Dubling passed a new DST rule adjusting the clock back by 15 minutes at 2025-06-20T16:50:00+02[Europe/Dublin] - then the meaning of the instant is different because now there’s 2 different `2025-06-20T17:00:00+02[Europe/Dublin]` and which one you get will depend on when you deserialize.
Can you check out the Brazil example in the docs I linked? That really should clear everything up. It explains how a datetime in the future gets serialized, but after a DST change, that serialized datetime becomes invalid.
The way this works is by looking at offsets. Think of a time zone as a function mapping between civil time and physical time. Or, another way to think about it is a mapping from a civil time to an offset (which may not exist for gaps or may not be unique for folds) and a mapping from physical time to an offset (of which there is a bijection). With RFC 9557, you encode both the offset and the time zone into the serialized representation. Consider a case when you encode an offset corresponding to DST, and then DST is abolished. Your tzdb is updated. Then you go to deserialize this datetime. Its offset no longer matches the rules. This can be detected and Temporal reports an error. This is all explained in the docs.
Note that DST is only an example here, because it's a common manifestation of how this error arises. But it can happen with any change in offset.
So if you're in 1760 and you write down a datetime in the future using the rules of that time (of which, I'm not even sure that's a sensible question to ask), then you'd have a particular offset encoded in that future datetime. Now fast forward to the future and the rules have changed and are no longer consistent with the offset encoded in the datetime. Thus, you get an error.
Think of it like this. In an RFC 9557 timestamp, you have an offset and you have a time zone. Those two pieces of information may be inconsistent with one another. For example, `2025-01-30T17:00+10[US/Eastern]`. When that happens, you can report an error. That's pretty much it.
> then the meaning of the instant is different because now there’s 2 different `2025-06-20T17:00:00+02[Europe/Dublin]` and which one you get will depend on when you deserialize.
If the region adjusted their close back by 15 minutes, then the offset would change. As for `2025-06-20T17:00:00+02[Europe/Dublin]`, it can only feasibly have two different interpretations: you can either interpret it as the instant `2025-06-20T17:00:00+02`, or you can interpret it as the civil time `2025-06-20T17:00:00` in the time zone `Europe/Dublin`, ignoring the offset. Or you can reject it. Temporal supports all of these modes, and it will by default reject such strings when the offset and time zone are inconsistent.
(There's a fourth mode, "prefer offset," that I won't get into here... It's not usually used for deserialization/parsing.)
So in my use cases, there's three types of dates that matter:
1. Past dates. These can be stored UTC, and just rendered in the appropriate timezone as a matter of formatting.
2. Future non-human dates: e.g. the next execution time of a job that runs every hour. These can just be UTC
3. Future human dates: I care about the human selected timezone so that events happen on the wall clock time the user expects. The UTC time and UTC offset are meaningless.
So in cases 1 and 2, having a non-UTC date is not required, while for case 3, the only thing that UTC offset is doing is adding information that could be inconsistent or confusing.
e.g. If the concert is on at 2026-01-31T18:00:00[Europe/Dublin] , that's all that matters, whether that ends up being 2026-01-31T18:00:00+00:00 or 2026-01-31T18:00:00+01:00 is unimportant for whether the building is going to be open at the time. So the system failing to give customers on the day of the concert a countdown because `2026-01-31T18:00:00+00:00[Europe/Dublin]` has become inconsistent because e.g. the EU actually did go ahead and abolish DST is suboptimal.
For that specific use case, sure! But Temporal isn't for Macha's 3 use cases. Not all future datetimes are only concerned with civil time. Some are concerned with the precise instant in time. So how do you choose which one? There is no one universal right answer, so IMO, the right default is to reject.
But if you know your use cases and know you always want to adhere to civil time even if it means a change in the precise instant, then Temporal supports that too:
>> zdt = Temporal.ZonedDateTime.from("2025-06-20T17:00+08[US/Eastern]")
Uncaught RangeError: Offset +08:00 is invalid for 2025-06-20T17:00:00 in US/Eastern
InterpretISODateTimeOffset ecmascript.mjs:1467
ToTemporalZonedDateTime ecmascript.mjs:1531
from zoneddatetime.mjs:478
<anonymous> debugger eval code:1
>> zdt = Temporal.ZonedDateTime.from("2025-06-20T17:00+08[US/Eastern]", {offset: 'ignore'})
>> zdt.toString()
"2025-06-20T17:00:00-04:00[US/Eastern]"
> So in cases 1 and 2, having a non-UTC date is not required
If the only operation you need is formatting, then I agree, you can apply the time zone to the instant right before it's displayed. But there are many other operations (such as arithmetic or computing durations between datetimes) you might want to do that do required a time zone. You might still be able to get away with only storing a UTC date, but it really depends on what you're doing.
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.
In other words, 2025-01-01T00:00+02:00 was NOT Europe/Paris (as it was CET at that time, GMT+1), 2024-08-01T00:00+02:00 could have been Europe/Paris (CEST, GMT+2), 2030-08-01T00:00+02:00 may be Europe/Paris (CEST, GMT+2), or perhaps not (CET, GMT+1). Or it may be a completely different TZ that incidentally shares the same offset at that 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.
Sounds great. I've been working with kotlinx-date time for a few projects on both the JVM and in browsers using kotlin-js. Because this is a multiplaform library that needs to work on multiple platforms it sort of is stuck with the lowest common denominator; which on kotlin-js was the old Date API.
The way this kotlin library works is that it implements a modern API that uses the underlying platform rather than re-implementing a bunch of things. This is mostly not a bad decision but it does have its limitations. One of the limitations is that not all platforms exposes a sane way to e.g. resolve timezones by their name and localize times while taking into account e.g. day light saving. Fixing that basically requires dealing with the time zone database and not all platforms expose that.
I ran into this recently. I managed to work around it as this is something you can dig out of existing browser APIs but it was annoying having to deal with that. Unfortunately there are probably a few more obstacles on other Kotlin platforms.
And while people in London might start work at 21:00, folks in Oxford might start at 20:55 and folks in Norwich might start at 21:02.
Time zones aren't just so everyone on the planet can start work at 09:00 local time. They're also for snapping everyone in a region to a shared time, even if it's a little off from their solar time.
Travelling would be so much more annoying if we did it that way. Imagine constantly having to double check what the local time is for getting out of bed.
How would that be useful for humans? Machines should make life easier for humans, not vice versa. For humans, I don't see any benefit to having to use a universal timezone. Being able to talk about time in a relative manner without converting timezones is very useful. I don't want to check timezones whenever someone tells me that they had to stay up until midnight, or wake up at 4am lol.
It always cracks me up when people think they are proposing a simpler system by ignoring complexity. Is akin to people saying, "why don't we just change the start/end time of schools/businesses instead of changing the clock back?" As if getting companies to agree to when to make a change, and updating all of their documents/signage/etc. would somehow be easier than allowing them to continue to say "open at 8."
For this one, It really amuses me on how they think they would accomplish keeping someone's phone to alarm at the equivalent of 7am when they fly across a nation.
Granted, I still hold the silly view that we should probably change daylight savings time to be a 10 minute change of the clock every month. Up for six months, down for 6 months. Would effectively be trying to tie it to actual solar time, which is what we seem to care about. And would be trivial with modern devices. (Though, no, I don't hold that this will happen.)
Well i mean, why stop there. We could alter the time of every clock every day by milliseconds or seconds, to keep perfect track of the solar timing. Better yet we could just trash the clock all together and decide to care about the things that got done rather than the exact time spent on it. This is probably not sarcasm
If we could easily change the duration of a second, I'd see little argument for why we wouldn't do that. Some of these solutions are easier than others.
Amusingly, these difficulties aren't static, either. Easy to argue that before rail and modern time pieces, what you are talking about is exactly what happened when people were using solar clocks.
Your idea is a lot better than my plan. When I am king of the world, no business or transactions will be allowed to occur on Feb 29th. Instead, every 4th year there would be a nothing day, where nothing happens. So no systems would ever have to deal with leap days or 366 day years.
My bank opens at 9am. My pharmacy opens at 8am. The corner cafe opens at 7:30 but is completely closed on Wednesdays. This "complexity," if you want to call it that, requires very little cognitive load, and certainly doesn't require any standardized features to be added to every operating system and programming language standard library.
The complexity I was referencing was having all businesses change by exactly the same amount on a given day. Which happens relatively flawlessly twice a year in much of the world. Just having them be different times for different companies is a completely separate thing.
Yes, but that's still all the same ballpark. It's useful to know that 9am is in the morning for almost everyone. Yes, there are exceptions but they are still just that - exceptions. I'm not sure how useful it would be to add even more chaos.
And again, it's a weird inversion in the role of a machine. Machines should make life easier for us, not the opposite.
With the "system" proposed in the comment I replied to, at which time will those businesses open in New York? London? Delhi? Tokyo? And why at those times?
It's so much nicer than what we're used to working with!
I built a set of low-level calendar components for building date/range pickers [0]. In anticipation of Temporal landing in browsers I decided to forgo Date (at least on the surface, I hid it away) and polyfilled the slither of Temporal I needed. When it lands I can just delete a bunch of code. The components come in at less than 10kb already, so I am looking forward to making them even slimmer!
Same! We've also been using the polyfill in production for a ~year or so.
We recently configured the node-pg driver to leave the postgres DATE / TIMESTAMP / TIMESTAMPTZ dates as "just strings" (instead of its default parsing to JS dates), and then we go straight from strings -> temporals at our ORM layer, without the jank/hop of it first being a JS Date.
But it's been great, having `DATE` in the db => `PlainDate` in the TS backend => `Date` in GraphQL API => `PlainDate` again in the TS/React FE. Very clean.
It has a single dependency, and that single dependency has no dependencies of its own.
So what is that dependency?
"temporal-spec"
And it looks like it comes from the same github repo. It basically looks like they broke out the API definitions so that they could be depended on by other potential implementations. This isn't atypical.
If payload size is the top concern you shouldn't be using Moment either though. Luxon and DayJS are both considerably smaller (their uncompressed size is about what Moment's compressed size is) and the date-fns library is much, much smaller and also tree-shakeable. Moment also performs at or near the bottom of all available options if speed is a concern. Other than reflexive popularity or the cost already being paid there's not really a good reason to use it anymore.
To me, timezone translations as well as durations are such an essential thing which libraries must handle, and it's nice to see that Temporal handles both. But it looks like Temporal.Duration doesn't offer a custom `format` function, for example `duration.format('H\hmm\m')` or something like that to format a duration into 1h03m.
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).
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, "now get Records and Tuples going too! You can skip that silly Pipe-syntax war if you want!"
Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to have gotten much adoption in the first place, I constantly run into cases where I'd want collections with structural equality.
Additionally, my understanding is that the opposition to adding new primitives also affects pattern matching, though I'm not sure why. I'm much less up to date on that proposal.
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.
I know why people needed it. It’s obviously useful. However, it’s still a relatively niche use case and rarely encounter people using it, especially compared to how many people I encounter asking about dealing with compound keys in maps or how to deeply compare two static blobs of JSON-style data. I understand why the implementers felt burned by its lack of adoption given its burden of implementation, but I’m also a bit surprised they expected more use.
Could you clarify which part you’re referring to? I’m disappointed at them feeling trepidation after BigInt, but the thread I linked (and some other discussions I’ve seen) make me understand why they’d choose to focus effort elsewhere.
It would be a monumental change and it’s not entirely clear how much of the community outside the React and similar ecosystems would adopt it. It might have significant performance issues for the desired use cases and choices about value semantics would affect usability.
It's great that Temporal is coming, and I'm sure there are bunch of other nice things coming up too, but unfortunately I don't share your optimism with the specific proposals that you mention (even though those would be very nice).
Pipelines, pattern matching and records+tuples have all been in the works for 4+ years, and are all still in stages 1-2. I don't think any of them has seen any significant progress in the past year, except maybe pattern matching. According to an issue in the records and tuples repo, there's been pushback on the value semantics of it (i.e. whether === can be made to work). Dropping value semantics would significantly reduce the whole proposal's usefulness.
I think all of them are at least a year or two away from reaching stage 3, if they ever do. But hey at least we now have array grouping functions.
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.
It's going to end up looking a lot like C# [0][1]; these two/three (JS/TS, C#) languages have been converging for a while now. Now just waiting for C# to get official first party discriminated unions!
Just an FYI for those unaware TS & C# are both creations of Anders Hejlsberg & his colleagues at Microsoft. Both are some of my favorite languages as well.
We would all benefit if JS was more like C# in my opinion.
Only if you haven't already declared the variable. e.g.
let x;
console.log(x = 'hello');
My point is that the `x = 'hello'` part is an assignment, and an expression, and has the exact same semantics regardless of whether you use that expression as a statement. So, assignments would seem to be expressions.
Unfortunately that proposal seems to be kinda dead.
React is a fundamentally flawed framework because of the lack of this feature. It inverts the responsibility of any non-primitive prop by putting the burden on the parent element instead of the child to decide when to rerender things. So elements are no longer self-contained if they receive any non-primitive values (besides react elements).
The React compiler auto-memoization that facebook is pushing also addresses this issue through build-time magic. I not fond of this approach.
Records.. Wasn't Dictionary an ECMA5 proposal or was that just a novel touch in AS3?
[edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly typed keys of any kind you specified. Errors thrown at compile time. God..I miss that language.]
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.
> Record/Tuple objects are immutable primitives with structural equality
TIL and also god that would be amazing, almost to the point of making JS/TS actually nice if done right (what’s next, pattern matching?). The number one footgun in JS imo is the combination of mutability and reference copying. Immutable or at least easy-to-copy plain old data is fantastic when it is well supported in the language.
It's not just the major browser makers. I was working on a JavaScript inference engine around when ES6 started to roll out, I had decent ES5 support but when all the syntatic updates came I had to give up. They basically killed the JavaScript ecosystem with all the updates. 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.
> 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.
Even when it does ship it'll probably be another year before enough browsers have updated to safely use it in production. So you'll need a polyfill. Which you can start using today anyways!
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?
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's handled in the standard library. What about Temporal and my visitors' browser?
Reading the proposal page “ Time Zones and Resolving Ambiguity”[1], it only mentions that it uses the IANA time zone database[2] not when it updates it. However I imagine the users computer has access to this database as well and probably handles it being updated. I’m not sure about this. It’s also entirely possible for the browser to download this database and maintain it too, separately from updates. I’m sure it depends on the implementation.
Since it's built into the browser it's probably updated when the browser is updated. Browser vendors did a lot of work to update quickly, browsers are probably the most up-to-date software on your average person's computer.
If you're running years old js runtimes in a bigcorp that doesn't feel like updating for the next decade, I'll pray for you. (Because there's nothing else to do.)
Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20
I work with both node and Python. The difference in upgrade experiences is measured in several orders of magnitude. My most recent few projects jumped Python versions because features I wanted were introduced. I cannot remember a time I had to rewrite application code because of an upgraded Python version (well I do, it was the Python 2 to 3 migration a very long time ago).
In the meantime new node versions constantly break backwards compatibility. Upgrading packages is a mess. Runtime environments are not properly isolated, third party packages sometimes explicitly do not work with specific versions of node, etc. For a community so focused on creating tooling, it has the worst tools of any ecosystem I have seen. I would rather work with C than with node.
Really, can you give a more specific example? I have never had a node upgrade break my code, and would be fairly surprised if I were to run into that situation! I also don't quite understand your other points - runtime environments are isolated, that's the point of the node_modules folder, and it's one of the things that Node/NPM does particularly well at. Were you installing your packages globally?
See my other comment but also npm is installed globally and global packages are available so there is no isolation. Compare to Python where a virtual env is complete with a separate copy of the Python interpreter, associated tools (pip, etc.), and only local packages are available. And best of all, you can call binaries inside the virtual env from outside it as normal executables and it just works. No need to mess with $PATH or set any other env variables, just call ./venv/bin/foobar and foobar will run in the context of that venv. Recreating this on a different machine is amazingly simple if you can use one of the already available Python binaries on that system, and trivial if not (compiling Python takes a few minutes and there are lots of tools that will make that process even simpler than the two commands you need to do it). People talk about Docker being the universal environment to run things but Python development doesn’t even need that 99% of the time. And the standard library is chock full of sane, performant modules that allow you to do everything you need, from asyncio to parsing arcane binary formats. My installed packages typically number in dozens, not thousands like JS, because the standard library provides so much already.
Yeah it’s pretty much this. Something simple like scss/sass breaks a little too often but that’s the easy case. When it’s a Postgres driver it gets even more interesting.
Using only the bundled APIs of node and python, I feel like python breaks more often, like for example the useless rename from `collections` to `collections.abc`.
Oh man 12 -> 20 must have hurt. In my experience, Node really stepped up their game in most any regard after the iojs split, and these days I've had almost zero problems jumping from one major LTS release to the next.
Can't guarantee no issues, but my gut feel is you'll have a much better experience with 20 -> 24 for example.
I know it doesn't always work out, but it definitely helps to keep current, rather than performing a massive update every X years. Most of the time the changes are minimal, but they add up over several major revisions.
Of course, every now and then something like eslint will completely break every project in existence by changing the configuration format, then you have to wait for all of the plugins to be updated (if ever), then hope all your linting rules are still valid... yeah I'm still bitter about that one.
I just moved an eslint config from a project started a little over a year ago to a fresh project and migrating the config took up way more time than I expected. The old config had options that didn’t make sense in the new config, or that weren’t covered in the migration docs, etc. I think it all works now but who knows if some odd rule got missed and that’s just that from now on
Picking Javascript as the foundation of your project and being dismayed at how much work it takes to keep up is a restatement of the definition of insanity.
On Unix systems (including Linux distros, macOS and Android), there is a system copy of the IANA Time Zone Database. I actually don't know if browsers use that or if they ship their own copy. But Temporal definitely uses the IANA tzdb.
> If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours?
Yeah I think this is generally correct. But I don't think that's a departure from current norms? I think this is also just true in general. If the user doesn't update to their system to account for new time zone transition rules then that's just kinda how the cookie crumbles.
The alternative is that every application ships their own tzdb. And to be clear, some do that and sometimes it is warranted. But in general this would be wasteful and likely lead overall to inconsistency between applications and likely a slower cadence of updates. (Because now every application has to be updated and shipped out again.)
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.
It's going to depend on the implementation and the system. The implementation will probably end up needing to define a time zone provider, which will ultimately be provided by host/system hooks provided to Temporal from the engine implementation.
They should add an event to detect when someone changes timezones. That could be another entry in the "falsehoods that programmers believe about time": programmers believe that your timezone is fixed during usage. But in reality there are millions of people moving between timezones every day.
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()`.
Where would you expect this event to be used? I don't think most web applications somewhat dependent on time should directly have to listen and respond to these events for the amount of people affected by it just doesn't justify the extra effort, I would assume. Libraries could benefit, of course.
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.
You couldn't just rely on a timezone change event for that though. You'd need to track it at the application level because it might not be open when the timezone changes.
> First JavaScript is unfortunately not just for web apps. It’s also for desktop apps.
A bit of a tangent but I’d say server is bigger than desktop. Like it or not JS (or TS) is the only cross platform development language that’s feasible today if you want to use a single language stack. As much as I despise the JS ecosystem practices and haphazard tooling there is no point trying to put the genie back in the bottle.
JS could be an amazing language to work with if they'd just spec out a "use type" subset that uses an actually-sound Hindley-Milner type system on typed parts (verify types at the untyped fringes and throw if they don't match) while disallowing all the bad parts like type coercion or any of the many other footguns in the language.
Typescript doesn't do ANY of that. It is intentionally unsound. Rather than prevent the crazy from happening, TS gives loads of ways to abuse the worst parts of the language as it slowly expands to be one of the most complex type systems ever created.
Finally, a "use type" with guaranteed type boundaries could offer loads of runtime optimizations and speedups that TS cannot offer (and has no intention of offering).
JS JITs like v8 is already do this to some extent.
Objects aren't actually "untyped". Every object has a hidden class with a definite type or "shape" (a shape basically means the same keys with the same value types in the same order). The inline cache (IC) stores which shapes have been used (and how often they've been used) for a specific function. The shape is checked every time the function is run with a series of assertions.
If your function only ever sees one shape, it is monomorphic and will get a lot of great optimizations not only on itself, but maybe on it's parent function as monomorphic functions can be inlined (one of the most important optimizations) with some asserts to make sure things went as expected.
If a function is called with 2-4 types in the IC, it is polymorphic in v8 which slows down the IC lookup and disables some optimizations. More than 4 types is called Megamorphic in v8 and is the slowest possible option.
Untyped -> typed simply does what already happens, but the assertions throw if they fail.
Types have other advantages within a function. There's a tradeoff in optimization where you don't want to optimize too early because you might have gotten it wrong and wasted a bunch of time and energy. Types make guarantees that your optimizations are correct which means you can optimize more earlier and there may even be optimizations that would simply be impossible otherwise.
A strong type system would disallow some of the stupidly-dynamic JS stuff which prevents optimization. This is an indirect massive benefit of a good type system (one that TS misses out on as it makes it easy to make types for very slow code patterns).
Typed -> typed is another important consideration. Instead of waiting hundreds of runs for your simple `.map(x => x.foo)` to inline, strong type guarantees mean you can inline it from the very beginning and all those useless assertion conditional branch instructions simply aren't needed. Polymorphism slows down current operations as it waits to dispatch, but because the types show what polymorphism exists and exactly which variant each call site uses, you can always match the exact call site to the correct monomorphic variant which also speeds things up.
Typed -> untyped is super-easy. The compiler knows the shape of the typed objects. It could probably add a greater weight to typed IC entries executing so they produce optimized versions sooner because the types add stronger consistency guarantees.
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.
The client's timezone should only matter to the client. There's no condition where their clock matters except to translate a timestamp into their local time (for their convenience). Who cares if they change time zones?
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.
I agree that it would be a nice feature, but I'd really have to be scraping the bottom of the feature barrel before I got to this. Unless my product heavily featured scheduling, or was a clock.
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").
Since this requires state to track should be up to the developer to define how they want to track and respond to changes in timezone? I'm not sure I would want Temporal to have an opinion on how to handle that?
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.
To be clear, the operating system is responsible for keeping track of timezone changes. Every major OS has a way for applications to be notified when the timezone changes. The major browsers are already hooked into these notifications, so what I'm suggesting is that when that event is received by the browser they should also emit a "timezonechange" event on the window. Any further handling is up to the developer.
You might but that isn't useful. Basically a web app will show you a time affected by your tailwind and weird geopolitics. (The weird politics are not so bad if you stay in the same time zone just changes 2 times a year)
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.
How so? UTC is a constant point in time. The difficulty lies in representing the value correctly, but the point in time is unchanged.
Unlike what sibling comment mentioned, if an appointment is scheduled at 1739287704987, the value will be the same regardless of where and when it's accessed from.
Yes, but they're saying that only works for past events. If you book a dentist appointment in the future using a timestamp, but then the tzdb rules change, you'll wind up with an unexpected result. (Because the civil time will be different and people usually book appointments based on civil time.)
Really depends on what you want to do. If it's something like "set the date at which new system behavior x becomes effective", UTC is perfectly fine; for scheduling a meeting, not so much.
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.
How would the runtime know that though? If you're in a plane with no internet, or if you're privacy conscious and you have location services turned off, there's no way for the JS engine to know you're in a different timezone.
I mean your argument has some merit but I'd argue that "you get the new timezone if you create a new date after your system updates its local timezone" is good enough.
Furthermore, most applications will just use UTC; local timezone is more used to adjust the displayed time, and even then it's opt in (e.g. someone reading a log will want server time or UTC, someone using a calendar will want to see their local time OR the time at the location of an event, etc).
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.
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'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.
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)
It looks like `.epochMilliseconds` should work as a Map/Set key/member in some situations, though you'll need to preserve the instant in the value in the Map case if you want to preserve the zonedata / do further operations on the Instant.
For the Set case you could use a Map{v.epochMilliseconds:v} and preserve the Instant.
Not great, but I think we all blame JS for this rather than Temporal. This could be made to work by the runtime but then polyfills would fail.
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.
Because it is impossible in JS? Except some crazy hacks, similar to how Java's constant string pool works, where every used object is a reference to a value in a pool of all objects.
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 guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).
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!
I get that the naming Temporal is used for avoiding conflicts with typical time objects like Moment, Datetime, etc. But isn't it a terrible name? At first glance I thought it was some kind of garbage collection control
We're definitely bike-shedding a decision that has already been made, but I agree that it's a horrible name.
First, "Temporal" is an adjective, not a noun. It might be related to time, but it doesn't make intuitive sense.
But more importantly, choosing an odd name because it has a lower probability of conflicting with old code will just make the language increasingly obscure over time.
When they added Promise and Generator, there were plenty of libraries that used those object names. It didn't matter, because unlike reserved keywords, you can override built-in Objects.
In my opinion the standards committee needs to have backbone and do the right thing for the long-term health of the language and use "Time".
But again, I'm sure this argument has come and gone and the decision has been made and agreed upon by all the browser makers and JS engine implementations.
I also think it's a terrible name. I'd even take DateV2 over this. I get they need backwards compatibility but Temporal sounds terrible. DateTime isn't by standard part of JS so why not use that? Until then const DateTime = Temporal
While I love that javascript has been taking features from popular libraries (read: jquery) and integrating them into vanilla, I do despair a little that every time it does so with a much more verbose and annoying invocation.
> When JavaScript was created in 1995, the Date object was copied from Java'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.
I'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?
Well browser standards were pretty much gimped by microsoft during the IE5/IE6 era, so from 1998 until around 2010 there was no progress on standards and Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share.
From 2010 until about 2020 I would say the standard committee took hold and they have been quite busy with other things. Since JS is a language defined by committee it can take quite some time for people to agree on APIs which is a subjective topic. The last thing the standards body want is to introduce an API and then deprecate it in favor of another API slightly later.
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.
I would say the darkest era was after IE7 was released: 2006-2010.
You could see all the new features, you could use them, you could design your site around them. But so many people refused to upgrade, so as a web developer you were forced to do stupid things to make IE6 work.
And it's not like IE7 was that much better. You needed to put effort into making that work too. At least Chrome and Firefox would usually both do the same thing.
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.
Not to the same level as back then, the closest thing would be Apple refusing to implement good PWA integration and Web Push Notifications (forcing people to use Apple Push Notifications which only works in Safari). PWAs are still (mostly) supported in Safari, they just don't integrate at the OS level in iOS.
Apple is still actively developing Safari and JSC and implementing standards, Microsoft basically COMPLETELY FROZE browser improvements for 10+ years. Worse even, they pushed proprietary Microsoft-only solutions to try to lock-in people.
Javascript, for the longest time, was a _slow_ moving target - web browsers themselves had cross browser issues where API X might work on browser A but not on browser B.
There were so many bigger issues like that I think that made this not a high priority in the grand scheme of things.
I think a good example of this is jQuery - while jQuery is a good tool, a huge part of its usage was the quirks between browsers. Selectors and the class of problems jQuery solved had more immediate impact to web applications, so fixing and taking from it became a more immediate concern.
JS API -> moment/date-fn/luxon -> Temporal has the same kind of trajectory. Not that those libraries will now be immediately 'bad' mind you - just that the base API is more sane.
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.
If that date's correct, they replaced it with another flawed implementation. The 'good' one came much later: https://jcp.org/en/jsr/detail?id=310
> What are the forces at work here?
I feel like I'm always simultaneously engaged in about 5 HN threads at a time, advocating for some combination of immutability, type-safety, and/or no-nulls. It's basically all I do.
By and large, people simply aren't into it. "Because the world is shared and mutable" is a pretty common rebuttal:
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!
I've been a JavaScript developer since the nineties and I too have been puzzled about this very thing. Everyone has known Date has been broken for a very long time and a plethora of pollyfills and datetime libraries have sprung up to band-aid the situation but nothing ever got close to being resolved as major ECMAscript versions were released over the years. I guess if it takes 270 pages for MDN to explain it, it's a rocket science problem that's well over my head.
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.
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.
My work does a lot of stuff with time and scheduling, and let me tell you having timezone-unaware date/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? https://bundlephobia.com/package/moment@2.30.1
moment.js has been obsolete for years. I've considered it as a sign of an unmaintained code for at least ~5 years by now.
There has been so many better and lightweight alternatives for years that if you haven't already refactored it away, you just don't care about your users or the bundle size. (And I have personally done that exercise a handful of times myself, I know it can be painful, but it's just one relatively small PR!)
Hey now, I'm offended. I maintain my app. I just have better things to do than constantly upgrade and strip away old libs because the JS kids have moved onto the next hottest thing.
As mentioned a couple posts up, it would certainly help finally stop a lot of web applications (generally accidentally) bundling a bonus copy of the entire IANA TZ DB via Moment.js including it all by default "just in case". Cutting a lot of poor tree shaking out of the web by truly and finally "killing" Moment.js will be huge in download sizes if nothing else.
I would start by arguing that not every website needs to deal with dates and times on the client side. And furthermore, if a website only needs to deal with dates but not times (surprisingly common) it can be done in a few KB of JavaScript—the Gregorian calendar is easy compared to the mess of ever-changing time zones and leap seconds.
I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience.
I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.
I'm afraid you have missed the point. My point is that most of the time you don't need datetimes. You only need dates.
Think about sites like blogs. The user only needs to know on what date a blogpost is published. Likewise for newspapers: we have hundreds of years of paper newspapers where people know on what date an article is published but not at what time. Think about banks. My bank tells me the date of a transaction, not its time. Likewise for brokerages.
> 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? https://bundlephobia.com/package/moment@2.30.1
In reality, it probably means adding yet another polyfill to the list.
Tangentially... Why did you quote the entire parent post? Quoting a small subset of a large post to respond is one thing, but copying the entire post into a reply adds unnecessary repetition and visual noise to the thread for no benefit. (Is it just me or is this becoming more common?)
I've needed these custom selects so many times... Including right now and I'm dreading building one from scratch again because all the libs I've found are lacking.
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.
It standardizes it across platforms and implementations; I mean you mention Moment.js, but it's been superseded by Luxon and DayJS ages ago; Moment is very large in terms of file size and doesn't support tree shaking, it creates mutable objects, same as Date, etc etc etc.
But there's the problem. Use momentjs today and you're behind the times, but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years.
> but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years
JS doesn't really have breaking changes. Until they do, MomentJS will always work.
> It standardizes it across platforms and implementations
Does it? I mean it prints the date and is a standard library, but I don't think it standardizes anything. Web doesn't really benefit from everyone using the same date library. It's all strings once it's sent over the wire.
One reason Temporal is a huge deal is because it differentiates between Date, Time, and DateTime. All of the libraries building on top of jsDate couldn't really do this effectively. I've been using Temporal in production now for about 2 years with a polyfill and while this distinction can be annoying at first, the ability to be so much more specific is very helpful.
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's (already quite good) datetime support.
Carbon is a similar class in the PHP world that's inherited from DateTime. This gives a good description of how working with mutable timestamps can cause problems, because methods like $newInstance = $instance->addDay() modify the original instance and return it, rather than returning a copy that's a day later:
So it's best to mostly use CarbonImmutable so that a new instance is always returned, which works better for higher-order programming style that's closer to pure functional programming. I do wish that Carbon was immutable by default, with CarbonMutable as a fallback when necessary, but it's too late for them to change it now.
I could see a project using use..as statements and/or aliases in config/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.
> I could see a project using use..as statements and/or aliases in config/app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases
This wouldn't work the way you're hoping for. use statements are file-scoped; a use statement in config/app.php would only affect that configuration file, not the entire application.
Oh I was thinking of adding the custom CRBN or Carb or whatever as class aliases to the original CarbonImmutable class in config/app.php. I actually haven't used aliases yet though, so I'm going by the assumption that they "just work".
I've had problems in other projects too where I wanted to disallow use of classes like Carbon after declaring a child class that overrides certain behaviors, so that the code is more future-proof for newly onboarded developers who don't know the pitfalls yet. In C/C++ I would just do:
#define Carbon "Please don't use Carbon, use CRBN or CRBNMUT instead."
So attempts to use Carbon would show up as compiler errors. But there are no #defines in PHP, so I haven't figured out a way to do that yet :-/ Maybe I could declare Carbon as a constant somewhere or something. But I don't think there's a way to undefine constants for times when the original word is needed, like with #undef.
Honestly, the best way of going about this would probably be a static analysis rule. Enforcing "use CarbonImmutable, not Carbon" doesn't need to happen at runtime.
At first glance, this seems to be in the JodaTime/NodaTime/Js-Joda tradition of representing different "granularities" of date and time information with distinct types, e.g. with and without timezone information. I'm not sure if there's a formal relationship, since this seems to use different names.
I personally like that approach, but I'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?)
From experience with js-joda, there's a definitely learning curve compared to moment's "one size fits all" type for all things date related. But I found that a lot of stupid mistakes of the kind "a person's age is wrong for an hour after midnight during daylight savings time" are prevented by default.
Luxon is 23.4kB minified+gzipped, temporal-polyfill is actually 20.5kB. I'm surprised, I thought embedding all the timezone and calendar data and possibly translations would add a lot of bytes.
This is great. You need to write so much code to do conversion between arbitrary timezones reliably now. And even if you don't mind including yet another (large) dependency instead, even those almost all have problems around DST boundaries/ambiguous dates as you simply don't have access to the timezone rules in the browser right now.
Long-needed, though I think it'll take the ecosystem quite a while to catch up and standardize around it
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't be a super high priority for us
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's worth, moment is excellent too, but having good datetime support in the standard library is going to be fantastic.
FYI, the Moment.js docs recommend not using Moment.js[0]
> We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.
The author spells out a few pitfalls of Moment's design and why they're not addressing these as well as alternatives (Luxon, Day.js, date-fns, js-Joda)
Oh thanks for the rec! I was aware that Moment was marking itself as legacy, but Day.js looks like a bonus here. Hopefully we can begin making the Temporal transition over the next few years though.
Each time I see a programming language upgrade its base library to improve date/time handling, they all look eerily similar to the Java open source library JodaTime, which eventually became JSR-310 (essentially the "2.0" 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/time APIs.
Dates/Times/Calendars, and all the politics therein, is perhaps the second most complex thing computers are asked to do. The first being human languages (UNICODE, LTR Vs. RTL, CTL, Encoding, Sorting/Collation, Normalization, etc).
Everyone agrees that Date in Javascript wasn't very good, but getting agreement over how to solve thousands of legitimately hard problems takes time. My viewpoint is that it is IMPRESSIVE it ONLY took them 15-years to get this far, and I congratulate everyone and all the hard work it took.
Point taken, I realize it's complicated stuff. My gripe with it was more that other exotic features were being implemented while this was being neglected.
Having used the API with a polyfill, it is a bit verbose and may seem a little obtuse at times. However, it allows you to explicitly differentiate between Date, Time, (Plain)DateTime, and ZonedDateTime. I have had to fix plenty of bugs because a datetime in the browser, datetime on the server, and UTC got mixed up at some point, and this API makes that a lot more difficult (and not likely to happen accidentally).
Cannot wait. That said, somehow I don'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).
But red across the board at https://caniuse.com/temporal looks like it's still far away, and a 20Kb polyfill seems heavy compared to the 2Kb size of Day.js
that'll work as soon as everyone in the world agrees to download the latest version of their favorite web browser each time Western Sahara is reclassified
Well I failed one interview because to calculate number of days in between I suggested substracting Unix timestamps and dividing the difference by 86400.
I understand the interviewer wanted to approach the problem as non decimal number of months in a year and variable number of days in a month. One day as the most granular entity. I didn't even wanted to argue over leap years and why the year 1900 wasn't one. It was consecutive meeting in a row and I was too tired for his shit.
I'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's extremely capable.
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'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.
Luxon author here. Obviously I (and many others!) put a lot into Luxon, but only because it seemed so useful. Now that it's hopefully becoming obsolete, I get to look at it fondly as a nice bridge to the future, and I appreciate all the love it's gotten. All things end.
I spent a day fighting with date-fns trying to get some date calculations working and was to the point I was questioning if my entire approach was flawed because there was no reason I should be spending that much time figuring our some simple date calculations. Eventually I decided to try swapping to Luxon. 30 minutes later and it was all working.
I'm still guessing I misunderstood something fundamental about date-fns, but for now I'm advocating for Luxon.
For the longest time date-fns approach to timezones was "Do you really need timezones? Aren't UTC offsets enough?" which was pretty fatal for a date time library, no matter how simple and light it makes your bundle.
It looks like they did finally launch TZ support in September last year, and I haven't investigated it (and probably never will, given Temporal is coming a Temporal polyfill seems a better option)
Another way of viewing this would be that these and other implementations have paved the way for standardization, which would possibly never have happened without them.
Curious to see how Temporal works with JS on the client side!
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.
That's generally how that works for new things like this. It is rare for a new thing like this to be adapted by everyone at the exact same time.
Certainly within the context of browsers. There is a reason why websites like https://caniuse.com exist in the first place. If you pay attention you will also see that for APIs on MDN it will also have a browser compatibility list.
Time and timezones are a big and complicated thing, I'm not surprised / appreciate they're taking their time with it. A library is temporary (ha) and is often superseded (e.g. momentjs -> luxon -> dayjs), but standard libraries are in it for the long time (Date has been around for 30 years and will be around for another 30 alongside Temporal).
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.
Umm..I am not sure how the Islamic/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?
There's no geographic adjustment but at least there is some choice for users about which Islamic calendar variation should be used. For example, "islamic-rgsa" in JS is the Hijri calendar, Saudi Arabia sighting.
Temporal has built-in support for non-Gregorian calendars, including parsing, arithmetic, etc. so you can do things like this:
function chineseNewYears() {
const dt = Temporal.Now.plainDateISO().withCalendar('chinese');
const current = Temporal.PlainDate.from({year: dt.year, month: 1, day: 1, calendar: 'chinese'})
const next = current.add({years: 1})
return { current, next }
}
`The next Chinese New Year is ${chineseNewYears().next.withCalendar('gregory').toLocaleString('en-UK')}`
// => 'The next Chinese New Year is 17/02/2026'
Blog author here, I have to admit I enjoyed your comment. This is because it's mostly reference documentation, so each method of each class has it's own page, for example:
MDN docs tend to be very thorough and well-written. It looks like most of these pages are for various utility functions, each of which has its own page.
Can someone who's been following this explain why they're designing a new API instead of merging one of the successful open source APIs into the standard?
Are those open source APIs standardized though? JS and browser standards are a different beast altogether than e.g. date library documentation. They need to write and specify exact behaviour, so that multiple implementations can be written by all relevant parties.
There are plenty of very popular libraries that are low quality and/or have some major issues, popularity of a package is not necessarily indicative of a perfect design. When you put something into your language standard to be supported for the next 30 years you want to make sure it’s as correct for as many people as possible. “Oh this seems to work fine let’s merge it” is not a high enough bar.
It’s inspired by JodaTime which got “merged” into Java, so you could say they are actually just merging an open source project, it’s just not one of the common JS ones.
Temporal API is far more consequential than what was attempted before. Their proposal for serializing timezones is about to become the de facto standard extension to ISO 8601 (date/time).
The vast majority of websites should be calculating dates in a server and merely presenting them to clients.
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).
Similarly a form element for date times could simply return the UTC from the local choice.
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're special and don't need to follow any kind of logic for our timezones (looking at you, China but also basically everyone else in the world).
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'm sure I'll still be using Moment.js ten years from now the way I'm still using JQuery 3.x now.
Javascript is all we have for front end web apps now, impoverished as it is as a language. But excuse me if I don't get excited every time a proposal is rolled out to bring it close to the 21st century.
And that's fair, thanks to the compatibility guarantees, those libraries will continue to work long in the future. However, they're suboptimal; MomentJS is a relatively large and difficult to compress / tree-shake library, for example. Have you considered switching to Luxon? It should be a relatively small transition.
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's pretty comfortable to use.
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.
If you want to do the operation "add one day to this timestamp", you _must_ decide whether that timestamp is local to a specific timezone and which one. Otherwise you'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.
It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris).
[1]: https://www.npmjs.com/package/temporal-polyfill