I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug any day of the week.
Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases.
Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are:
- 23 hours
- 25 hours
- 24 hours 1 second
- 23 hours 59 minutes 59 seconds
You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close.
And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing).
To make things worse, those are "simple" edge cases.
Time is hard. I'm not sure if I can make any statement about time that is true.
I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second.
There’s no single time unit that works for all situations.
Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.
Ramadan is observed from one visual sighting of a crescent moon to the next.
Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.
> Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.
Only Morocco does this, I believe, and it's not even clear that that's actually official time at this point. In 2018, Morocco abolished DST, but it seems unclear what that means in practice.
I'd love it if someone from Morocco could weigh in on what the actual situation is on the ground. Do people still change their clocks for Ramadan? Would they be annoyed if a website kept Moroccan users on standard time during Ramadan?
In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?
Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself.
And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.
This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.
Given the stochastic nature, if I am forced to have to dig into the code because the LLM couldn't figure it out perhaps one out of every 10 times, it's still a huge bonus. Probably it depends on what you are working on. Esoteric COBOL? Erlang? Yeah good luck, you're probably hand steering the thing while the frontier model providers figure out how to train it better. Vanilla-ish Python/Golang/Typescript/Java? I pretty much never have to do that nowadays for things the model is familiar with. If i do have to dig into the code, I've never regretted doing it this way, because 90% of my use cases worked just fine, and in those 90% of use cases I was able to produce working code at 20x the rate of hand writing it if not more. Feels like a huge win to me.
Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.)
anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive changes after other implementers discovered what a monster it all is. The original version of the spec kind of forced two separate internal implementation paths for everything, one for custom calendars and one for the built-in stuff, just to make the built-in one reasonably performant. That was a lot of work to implement, and a lot of work to remove. (I think ptomato shepherded the spec side of that?)
Fortunately, anba knows how to take a break, relaxing occasionally with minor tasks like rewriting large swathes of the JIT code generator to optimize the support on various platforms. He also gets plenty of nutrition, by ingesting entire specs and mind-melding with them.
I feel like those not involved in this space might not realize so much stuff that benefits the entire web/world comes from volunteers like anba and companies outside the usual browser vendors. Whether you’re an individual contributor or you want to push your employer to contribute or let you contribute, the best time to get involved is always now. We owe anba a big one. Thank you!!
I went through a similar decade-long fire drill around ISO8601 date parsing in Python.[1] Issue started in 2012, and after about a decade a solution was in the standard library.
Parsing dates with anything other than fromisoformat feels totally backwards in comparison. We were using ciso8601 until fromisoformat was in the standard library. And now things are incredibly simple and reliable.
A big step in the right direction, but I still don't like the API, here's why:
Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize it easily.
This is not the case for Temporal objects. Also, the temporal objects have functions on them, which, granted, makes it convenient to use, but a pain to pass it over the wire.
I'd clearly prefer a set of pure functions, into which I can pass data-only temporal objects, quite a bit like date-fns did it.
This was an intentional design decision. We wanted to make sure all the temporal types could be serialize/deserializable, but as you mentioned, you couldn't implicitly go back to the object you started with as JSON.parse doesn't support that.
Instead the onus is on the developer to re-create the correct object they need on the other side. I don't believe this is problematic because if you know you're sending a Date, DateTime, MonthDay, YearMonth type from one side, then you know what type to rebuild from the ISO string on the other. Having it be automatic could be an issue if you receive unexpected values and are now dealing with the wrong types.
There are no date, time or datetime types in JSON, so you'll have to serialise it to a string or an int anyway, and then when deserialising you'll need to identify explicitly which values should be parsed as dates.
Well, you could still have a compound object in JSON, that is output by the Temporal API, and which given as input is guaranteed to result in an equal object it was created/serialized from. This compound object must contain all required infos about timezones and such stuff.
.... we're talking about serialization here. "convert to a raw string" is sort of the name of the game.
It's a string in a well specified string format. That's typically what you want for serialization.
Temporal is typed; but its serialization helpers aren't, because there's no single way to talk about types across serialization. That's functionality a serialization library may choose to provide, but can't really be designed into the language.
You realize that JSON isn't just for JavaScript to JavaScript communication, right? Even if you had a magical format (which doesn't make sense and is a bad idea to attempt to auto-deserialize), it wouldn't work across languages.
If you really want that, it's not very hard to design a pair of functions `mySerialize()`, `myDeserialize()` that's a thin wrapper over `JSON.parse`.
This is a real pain point and I run into the same tension in systems where data crosses serialization boundaries constantly. The prototype-stripping problem you're describing with JSON.parse/stringify is a specific case of a more general issue: rich domain objects don't survive wire transfer without a reconstitution step.
That said, I think the Temporal team made the right call here. Date-time logic is one of those domains where the "bag of data plus free functions" approach leads to subtle bugs because callers forget to pass the right context (calendar system, timezone) to the right function. Binding the operations to the object means the type system can enforce that a PlainDate never accidentally gets treated as a ZonedDateTime. date-fns is great but it can't give you that.
The serialization issue is solvable at the boundary. If you're using tRPC or similar, a thin transform layer that calls Temporal.Whatever.from() on the way in and .toString() on the way out is pretty minimal overhead. Same pattern people use with Decimal types or any value object that doesn't roundtrip through JSON natively. Annoying, sure, but the alternative is giving up the type safety that makes the API worth having in the first place.
Sounds like we need an extended JSON with the express intent of conveying common extended values and rich objects: DateTime instants (with calendar system & timezone), Decimal, BigInt, etc.
I disagree: this is not unlike including the schema in the JSON itself. This should be handled by the apps themselves, since they would have to know what the keys mean regardless.
If you do want the interchange format to be the one deserializing into specific runtime data structures, use YAML. YAML's tag syntax allows you to run arbitrary code inside YAML, which can be used for what you want.
I'm not talking about something arbitrarily extensible or compound values like vectors or lat/lon. Just a few more common data types -- primitive-like values that frequently need to be passed around.
This would probably best exist as a well-known wrapper around JSON itself.
there are a zillion of these "json pro" kind of things: superjson, devalue, capnweb, all with slightly different ideas about how to lower high-level semantics to json's available types. it's so easy to do this kind of thing, its a real https://xkcd.com/927/ situation.
CBOR (Concise Binary Object Representation) has JSON-like semantics with type extension support; with built in type extensions its much easier to get some agreement about registering certain magic type IDs to mean certain things. for example from a random google search for "cbor datetime" https://j-richter.github.io/CBOR/date.html; there's an IANA registry of type IDs: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
I think a more practical and compatible approach is to keep json as it is, and use a side channel (e.g. an openapi spec) to convey metadata.
Then it is up to the client to decide that a date returned as a string is a date or string, or to create a specific class instead of a generic object
For most situations, I deal with this by keeping dates as strings throughout the app, not objects. They get read from the db as strings, passed around as strings. If I need datetime calculations, I use the language's datetime objects to do it and convert right back to string. Display formatting for users happens at the last moment, in the template.
No-one seems to like this style, but I find it much simpler than converting on db read/write and passing datetime objects around.
It's not that much about type safety. Since TypeScript uses duck typing, a DateTime could not be used as a ZonedDateTime because it'd lack the "timezone" property. The other way around, though, it would work. But I wouldn't even mind that, honestly.
The real drawback of the functional approach is UX, because it's harder to code and you don't get nice auto-complete.
Updating JSON.parse() to automatically create Temporal objects (from what shape of JSON value?) without a custom reviver would be a step too far, in my opinion.
This is effectively no different from Date:
serialize: date.toJSON()
deserialize: new Date(jsonDate)
Don’t JavaScript Date instances have the same problem? Date implements toJSON, but when parsing JSON you’ll have to manually identify which string values represent Dates and convert them back to Date instances. The exact same is true of Temporal (e.g. Instant).
And as far as I know, date-fns deals with native Date instances, not “data-only objects.”
The serialization thing is real but I don't think OOP vs functional is the actual issue here. JSON has no date type, period. You JSON.stringify a Date, get an ISO string, and hope whoever's parsing remembers to reconstruct it. Temporal doesn't fix that part, but at least when you do reconstruct you're saying "this is a ZonedDateTime" vs "this is an Instant" instead of everything being one ambiguous Date object.
That's not what I mean. Even though it is serializable, it's still not the same when you serialize/deserialize it.
For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth.
You would need to use the `reviver` parameter of `JSON.parse()` to revive your date strings to Temporal objects. As others have said, it's a simple `Temporal.from()`
Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.
The main advantage of json is that it’s human readable and writable. Beyond that, it has no notion of user created data types so anyone using it has to do custom unmarshalling to get a type apart from sting, number, dict and list.
Even if you don't explicitly provide a schema, you implicitly still have one. The recipient needs to know what you're sending them. Unless maybe you want to start parsing JSON payloads with an LLM.
Which is why many developers only use JavaScript Object Notation for JavaScript objects, and only JavaScript objects that can losslessly be written as JSON. Which this proposal explicitly does not support.
> For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth.
I don't know if I'm missing something, but that's exactly how I'd expect it to compose. Does the following do what you wanted your snippet to do?
JSON.stringify and JSON.parse should not be viewed as strict inverses of each other. `JSON.parse(JSON.stringify(x)) = x` is only true for a for a small category of values. That category is even smaller if parsing is happening in a different place than stringification because JSON doesn't specify runtime characteristics. This can lead to things like JSON parsing incorrect in JS because they're too large for JS to represent as a number.
The JSON types are string, number, boolean, null, object and array. So how could the suggested code possibly work? Do you want JSON.parse to do arbitrary code execution like Python's pickle?
I'm with you on this. I worked on a big Temporal project briefly and I was really turned off by how much of the codebase was just rote mapping properties from one layer to the next.
> What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize it easily.
This is known as the "primitive obsession" anti-pattern.
> Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic
Which makes me wonder how it'll look like when interfacing with WASM. Better than Date?
yes, sure. probably there will even pop up a functional wrapper around the temporal API occasionally. But would've been nice if it was like this from the start.
Would have been interesting to connect back to Java's own journey to improve its time APIs, with Joda-Time leading into JSR 310, released with Java 8 in 2014. Immutable representations, instants, proper timezone support etc.
Given that the article refers to the "radical proposal" to bring these features to JavaScript came in 2018, surely Java's own solutions had some influence?
I would characterize it more as Joda likely informed Moment.js, which better informed TC39 because it was within the JavaScript ecosystem. As we discussed in plenary today when achieving consensus, every programming language that implements or revamps its date time primitives has the benefit of all the prior art that exists at that instant. TC39 always casts a wide net to canvas what other ecosystems do, but isn't beholden to follow in their footsteps and achieves consensus on what is best for JavaScript. So my view is this more represents what the committee believes is the most complete implementation of such an API that an assembled group of JavaScript experts could design over 9 years and finalize in 2026.
I'm in the C# world and can attribute most of my understanding about dates and times to Noda (the .NET version of Joda). Shout out to Jon Skeet for maintaining it.
Slower to implement new features, but still implementing them, just makes it the new Firefox. IE's larger problem was how popular it had been before it stopped implementing new features. It was like if Google got bored with Chrome and decided to stop all funding on it. People would be stuck on Chrome for years after that investment stopped because of all the Chrome-specific things built around it (Electron, Puppeteer, Selenium, etc and so forth).
Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". Safari's problems are temporary. Chrome is the new Emperor and IE wasn't bad because it stopped, it was bad because it stopped after being the Emperor for some time. People remember how bad the time was after the Empire crumbled, but it's how IE took so many other things down with it that it is easier to remember the interregnum after IE crumbled than to remember the heyday when "IE-only websites are good enough for business" sounded like a good idea and not a cautionary tale.
The biggest problem with IE from a developer standpoint wasn't the slow feature release cadence, it was that the features it did have worked differently from standards-based browsers. That's very much the position of Safari/WebKit today - code that works across all other engines throws errors in WebKit and often requires substantial changes to resolve.
Safari is also pretty popular on iPhones, in fact it has a full 100% market share. With browser updates tied to the OS, that means millions of devices have those "temporary" problems baked in forever.
When IE was the Emperor it was seen as IE's behaviors were the standards. The perspective at the time was that the other browsers were non-standard. That did get codified into the standards eventually. `* { box-sizing: border-box; }` that is towards the top of almost every "reset.css" is CSS standard for "use the IE box model". XHR was named XmlHttpRequest as an IE quirk and that set the standard we still mostly follow today; `fetch` is a nicer API but we still colloquially call it a part of/relative to/replacement for XHR including various browsers' Dev Tools where to focus on `fetch` requests you click the XHR tab.
Both of those things (and others) became "standards" when IE was moving quickly and breaking things. It took a while for the actual multi-browser standards to catch up. XHR took a few years to show up in non-IE browsers. CSS `box-sizing` wasn't added to the CSS standards until 2012 (11 years after IE6 was released, the "last" version of IE for a long time; five years without a new version). A lot of the web was built easier on those things or better with those things which lead to so many people using IE up to IE6 as their primary browser and so many developers building IE-only websites up to IE6.
Again, as a developer it can be easy to remember the pain of still supporting IE6 in 2005 (five years before tools like `box-sizing` made it a lot easier to support similar CSS for both IE and non-IE browsers, and a year before IE7 finally broke the "IE6 is the last IE" problem). It seems a lot harder to remember why we were still supporting a "dead"/"final" IE6 in 2005 or still supporting a "dead"/"final" IE6 in 2012 when IE10 was fresh and new and very standards compliant (including supporting both `box-sizing` modes) but not yet winning over the crowds of legacy sites: everyone was using IE6 until Microsoft killed it. A lot of things were built for its version of "standards" (many of which were better/easier to develop for versus their contemporary real standards) and couldn't be easily upgraded until the real standards also caught up to how fast IE had been innovating/changing/upgrading the standards.
The risk to the web platform that I think IE represents the most cautionary tale about is relying too much on the browser rushing ahead of the standards, because it could stop at any moment and may take a decade or more for the standards to truly catch back up. Because they did.
If Google decided today to do a "The Browser Company-style pivot" because the Age of AI means that browsers are dead, everything a browser can do should be done through agentic automation, and asked all of the Chrome team to switch to some new agentic harness or accept a soft layoff, how much work would there be to move websites out of being "Chrome-only" or built on top of Chromium? (Which to be further unfair is also sort of what feels like is already left of Microsoft's Edge team working in Chromium today.) It's real easy to imagine that hypothetical, I already named two companies working with Chromium that have just about done exactly that. The hypothetical is not that far from the inside baseball of what happened to IE6 where Microsoft thought browsers were "done" and pivoted the IE team to new roles on "higher priority" Windows work and/or soft layoffs.
We remember the pain of having to support older versions of IE pretty well, but not enough of us seem to remember the pain of how we got to that point and how easy it feels like companies could do that to the web again. Safari lagging current standards is a relatively smaller problem compared to if Chrome gets burnt we suffer another "internet dark age" of supporting ancient browsers for a decade or two due to legacy apps and in turn legacy users that don't or won't upgrade.
(Some would argue that can't happen in the same way that IE did because Chromium is open source and already has many forks. I can't help up but bring up examples like the word "diaspora" and the tale of "the Tower of Babel" that a messy soup of forks that no one can agree on as the new "standard" can be its own slow train wreck disaster.)
> Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back".
There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing).
> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing).
It's a matter of perspective. The safer perspective is: Safari isn't holding the web back, Chrome is moving too fast. Developers making Chrome-only sites and tools are moving too fast for the safety of web standards/web platform. Where one of the safety factors is "widely available in multiple implementations, not just a single browser".
> > Safari's problems are temporary.
> What are you talking about?
The point is that Safari may be moving slow, but it is still moving. It doesn't have enough users to hold the web back. It isn't "always a decade behind", it 's "a couple years to a couple months behind", depending on which caniuse or MDN Baseline approach you want to take.
There are some things Safari doesn't want to implement, but has registered safety or privacy or coupling reasons behind such things. Firefox is doing the same.
Safari isn't trapping website developers in "old standards forever", it is encouraging developers to use safe, private, stable choices. Chrome is "move fast and sometimes break things". Safari doesn't want to be that. That's useful for the web as a platform to have one or two browsers considering their implementations. It's a good reason to point out "Chrome-only" developers as being "too bleeding edge" (sometimes emphasis on the bleeding) and out of touch with standards and standards processes.
The only well supported and consistent argument I see in those links is that Safari is bad at PWAs. I agree with that. But (timely rant incoming) I also think everyone is currently bad at PWAs. The current ServiceWorker-based approach is brittle and hard to use because it is too low level and too tightly coupled to what seem to be Chrome-specific concerns. The previous manifest.json approach should have never been disabled in Chrome, it should have at least lived side-by-side and let developers vote by their feet, at least until a reasonably equivalent high-level manifest replacement was built.
I was just thinking about this this week because I have a webpage I built with offline capabilities and an excuse coming up where many of the webpage's users will be offline for a week but might have use for the webpage, but I can't easily turn it into a PWA because it was built as an MPA and there's no great high level tools for writing an MPA's ServiceWorker because most of the high level libraries are so (overly) focused on SPAs. I wish I could just put a manifest.json or some sort of zip archive users could download and have it share Local Storage.
I do pin a lot of this on Google engineers. The side effect is Safari is having a hard time implementing these "standards", but the real cause is the "standards" are over-complicated trash that are also hard to develop for. Everyone including the links you sent can see how Apple's App Store moat gives them an incentive to drag their feet on implementing these "standards" and yet no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards that are hard for anyone to use and harder for anyone else to implement is just another way to drag your feet and keep the whole web platform behind, without looking like you are dragging your feet.
It would feel different, too, if the fully declarative manifest.json approach hadn't briefly worked (well) in Edge (Spartan) and Firefox before Google derailed that standards train with "Chrome-first" ServiceWorker complications. Always seemed like one of the reasons that Microsoft just gave up on the web platform because they couldn't keep up with Google's machinations (and conflicts of interest) in Chrome.
It is bizarre that you're "pinning" this on the Chromium engineers - who are essentially the only ones moving the web forward.
The safari feet dragging/obstruction goes far beyond PWAs. The chart on this page is one of many examples showing how consistently far behind Safari is - they've been enormously behind chrome and firefox in coverage of tests for 7+ years. https://wpt.fyi/. And here's an extremely comprehensive article on the topic https://webventures.rejh.nl/blog/2024/history-of-safari-show...
As for standards, here's another detailed series to learn from https://infrequently.org/series/effective-standards-work/. Once again, you have it all backwards. Saying "no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards" is not only laughable, but just dumb - Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.
Moreover, it is quite clearly an institutional decision to hold back the web, or else they would allow for other browser engines to run on iOS rather than focing them all to be skins on webkit. Again, this is all documented in extreme detail in the articles on that site. If you find it to be still somehow lacking, the author is very open to discussion on bluesky or mastodon (I'd prepare far better though, because what you've said thus far would get eviscerated).
Also bizarre that you are saying that Google Play is somehow at the root of this supposed scheme to make web standards impossible for others to implement. Android is similarly against the web flourishing, but evidently not nearly as powerful in the greater Google enterprise as iphone/app store is in Apple.
As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.
And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.
I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.
If you are actually attempting to communicate in good faith, i can't recommend strongly enough that you read that entire site. And, likewise, read and support the work of Open Web Advocacy. https://open-web-advocacy.org/
> It is bizarre that you're "pinning" this on the Chromium engineers - who are essentially the only ones moving the web forward.
I'm saying this is exactly the problem. If the perception is that only one browser is "moving forward" and the rest are just chasing that moving target, that's not healthy and it is not a standards process. WHATWG has always been at risk of "regulatory capture" by Google or at least Chromium interests. More so than ever there are standards that seems like WHATWG rubber stamped whatever Chrome decided to do without larger consensus work with Safari and Firefox. That's really dangerous for the web platform. (And W3C lost to WHATWG and seems increasingly irrelevant as a standards body for HTML.)
I think we are all very lucky that ECMA hasn't so far shown the same risk and TC-39 (JS) continues to look overall diverse and healthy.
> Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.
This is why I put standards in quotes in most of that comment. I do think WHATWG has already signed off on Chrome-first things as "standards" that aren't in the sense of multiple robust implementations and a diverse enough number of stakeholders that aren't just using Chromium-derived codebases. I worry WHATWG is at risk of getting worse in this.
> As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.
As very personal experience from building PWAs (and failing to build many more of them): Workbox is bloated and awful to work with and is bad enough at SPAs that trying to feed it an MPA makes me want to scream just thinking about it. Hand-rolling a Service Worker remains a nightmare because the API is awful to work with by hand, which is the whole reason Workbox exists. There's something very wrong with the APIs that right now the only answer seems to be "just use Workbox". That's not healthy for the web platform to be so dependent on a single vendor's tool to get over the hump of using a web API. (Even if that tool is open source. CVEs affect open source like everything else.)
The last time I was serious about PWA development I broke down in tears and switched to Ionic's Capacitor and Electron because browser wrappers are still too much easier than writing a PWA.
I know that isn't just me also anecdotally by the number of Electron apps running on my machine even right now (a bunch) and the number of PWA apps running on my machine (none).
Statistically Service Workers and Workbox are massive failures, and it isn't Apple's fault and it is weird to me claiming that it is entirely Apple's fault. If you don't want to blame Google or at least Chromium engineers, that's fine, we don't have to agree on that. But show me the app with a working PWA ServiceWorker that has a good reliable caching strategy, good offline-first support, and people use that offline-first capability regularly and I'll show you a unicorn. The APIs are terrible, the standards should be better. If we don't want to point fingers at why the current APIs and standards are so awful, can we at least find someone to point a finger at who is actively working to make them better? It doesn't seem to be "Just Use Workbox" Chromium. Who is actually trying to move the offline-first web forward towards pragmatic reality and not just "we support it in theory, with this one JS library, but very few are using it in practice and almost none successfully"?
> And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.
When Microsoft switched to Chromium they soft laid off a lot of their web platform staff. Chromium Edge's outward development focus seems to be AI and First-Party Coupon Cutting Extensions.
Spartan Edge had ideals and seemed to really believe in the PWA as a first class application platform. For a time, I had a bunch of PWAs as daily use applications in Windows 8 and early 10 (not all of which I built myself, either). That era is certainly gone now. WebView2 is making some inroads in reduce the reliance on Electron by certain types of apps, but WebView2 isn't a PWA platform, it is another end run around it/away from it.
> I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.
> If you are actually attempting to communicate in good faith
You've strayed close enough to the realm of ad hominem attacks that I'm going to stop here. It doesn't sound like we are going to ever agree, but certainly not because I'm not debating in "good faith" or living in some "bizarro world". It seems rude to me to imply such accusations. Just because I have a different perspective doesn't make me a bad actor nor prove I have some sort of mental health issues. I may have experienced a different world than you have in my career, but there was nothing "bizarro" or worse about it. Different perspectives should be a joy to engage with, not an affront to ridicule. I'm sorry I couldn't find help you find common ground.
it would, indeed, be great if there were others contributing to the web. Mozilla should be, but they seem to be run by incompetent grifters. Apple could be, but that would be completely against their interests. So we're left with chromium moving the web forward - that's not their fault and its ludicrous that you keep saying it is.
as for service worker, I literally said you dont need workbox. I have done lots of hand-rolled MPA caching. Its dead-simple, so i dont know what complexity you're referring to.
As for the fact that there arent many good pwas out there - people dont bother because iphone is a mess. Your arguments would hold water if apple allowed other browser engines and then pwas still languished.
Even still, there's all sorts of efforts towards offline/local-first. Its a hard problem to solve. But, again, simple MPA caching is not hard. If its a dynamic backend, then that would be much more difficult
Deno has had it behind the `--untable-temporal` flag for quite a few Minor versions now and the latest Minor update (because of TC-39's Stage 4 acceptance and V8 itself also marking the API as Stable) removed the requirement for the flag and it is out of the box.
Converting between solar-based and lunar-based calendars is fraught with potential for ambiguity. The Buddhist calendar is a solar calendar, while the Hebrew calendar is lunar-based. So converting between dates in the Buddhist calendar and the international-standard (ISO 8601) calendar is typically easy (give or take some subtleties I won't go into for reasons of length). But converting between the Hebrew calendar and the ISO 8601 calendar, or the Buddhist calendar, involves figuring out when the new moon will be — and since the lunar cycle is 29 or 30 days, 12 lunar months add up to 354 days. So the lunar calendars, including the Hebrew calendar, typically add a "leap month" every two or three years in order to track the sidereal year.
All of which means there are many potential ambiguities in converting between calendars, and the combinatorial explosion possible means they probably only want you to convert between non-ISO8601 calendars and ISO8601. It would be too easy to get corner cases wrong otherwise and not notice, I'm sure. So to convert a date from Buddhist calender to Hebrew calender, you'd probably have to do Buddhist -> ISO8601, then ISO8601 -> Hebrew. (I haven't had time to test that for myself yet, I'll post a correction if that turns out to be wrong).
One of my favorite interview questions is asking a candidate to, piece meal, build a calendar. They start with Julian, and then write converters to and from other calendars. Any calendar can be converted to any other, by going through Julian
I got the idea from the book "calendrical calculations"
Yep, temporal_rs is designed with native Rust use in mind, so you should be able to use temporal_rs directly wherever you'd use jiff or chrono.
That being said, the library is designed to be specification conformant and with EcmaScript implementations in mind. There are some specific API choices made specifically for those clients.
That being said, we are always looking for feedback regarding the native Rust API. So feel free to try temporal_rs out and provide whatever feedback you'd like :)
Maybe I will be able to move away from my custom/minimal DT lib, and ISO-8601 timestamp strings in UTC. JS datetime handling in both Date and Moment are disasters. Rust's Chrono is great. Python's builtin has things I don't like, but is useable. Date and Moment are traps. One of their biggest mistakes is not having dedicated Date and Time types; the accepted reason is "Dates and times don't exist on their own", which is bizarre. So, it's canon to use a datetime (e.g. JS "Date") with 00:00 time, which leads to subtle errors.
From the link, we can see Temporal does have separate Date/Time/Datetime types. ("PlainDate" etc)
I wouldn't be surprised to see the Rust ecosystem eventually move to Temporal's api, given v8 (Chrome) adopted Boa's rust implementation temporal_rs (https://docs.rs/temporal_rs/latest/temporal_rs/), see burntsushi's arguments for the need of a better datetime handling library in Rust (https://github.com/BurntSushi/jiff/blob/master/DESIGN.md#why...). I'm not sure his jiff create will be the one, i think temporal_rs has become the authoritative implementation.
Yes, please try! One of the main motivations for doing all this work is to slim down both the amount of code that has to be delivered and executed by providing everything that's needed by the platform. In addition, you're slimming the potential bug/attack surface as well, which is always nice.
> Higher-precision timestamps (nanoseconds, at a minimum)
I get HFT, but I have a hard time comprehending a need for a Bloomberg Terminal to be talking in picoseconds, as in fractions of a billionth of a second.
Interval (https://www.threeten.org/threeten-extra/apidocs/org.threeten...) isn't built into java.time, however, it is in the popular threeten-extra library. The docs say "An interval represents the time on the time-line between two Instants." The main difference being that Interval is anchored to the timeline while Duration and Period are not.
The Java parallel is apt. Joda-Time dominated the ecosystem for about 8 years before JSR 310 landed in Java 8 (2014). One thing that helped there was a clear, single release target.
What I keep thinking about with Temporal is the adoption timeline question isn't really 'is it specced?' anymore, it's 'what minimum runtime version do I need?' Node.js, Deno, Bun all need to ship it stably, and then the practical floor for usage is wherever most prod environments are. The polyfill situation (@js-temporal/polyfill and others) doesn't really collapse until that happens.
So the speccing is done but I think we're still a couple of LTS cycles away from it being genuinely boring to reach for Temporal.
An example that is hard to follow defeats the point. It's just showing what pattern is possible and you can imagine the abstraction layers and indirection that would make it happen accidentally.
Most of that complication is there because times and dates are actually complicated. You can have a nice simple API that doesn't expose the complication only if you're happy for it to encourage false assumptions and wrong behaviour.
But, still, let's look at your first couple of complaints.
To make #1 more explicit: If you want the equivalent of "new Date()", then as you observe you need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does?
To make #2 more explicit: If you want the equivalent of "Date.now()", then as you observe you again need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does?
Well, because as those two examples show there isn't actually an obvious simple thing. Two operations both of which one might expect to do the obvious simple thing do different things, and if there's some obvious way for someone who doesn't already happen to have the specs of Date memorized to know which one is "new Date()" and which one is "Date.now()", I don't know what it is.
So, to me, those first two examples look like pretty convincing evidence that Temporal is a better design and one that's less likely to lead non-experts to make serious mistakes.
... And then your other two complaints aren't actually about the API being "too complicated" at all! PascalCase isn't more complicated than snakeCase. Nanoseconds aren't more complicated than milliseconds.
(Also: "zonedDateTimeISO" and "epochMilliseconds" are in fact both snakeCase, and a quick look at the Temporal documentation suggests that this is the norm. Method names are snakeCase, class names are PascalCase. I am not a Javascript expert but isn't that pretty normal?)
Thanks for sharing your thoughts too. I still have the feeling that broad adoption comes from simple things that just work. And the complicated stuff is more optional.
Doesn't the implementation being in rust for many browser (`temporal_rs`) make it possibly slower than it could be in pure JS? Calendar is not very intensive process, so I would not be surprised if the slowness of boundary passing make it slower.
Right, browsers own it instead of websites needing to rebuild Moment.js bundles. Additionally, most browsers pass the ownership further to the user's OS as the IANA timezone database is a useful system-level service and best updated at the cadence of OS "required" updates.
Typically time zone data is updated in IANA's time zone database. That data would need to be updated in the implementation. In this case, the browser would need to update their time zone data.
Depending on the situation, the data lives either within the browser or within the OS. Chrome releases ship versions of tzdata that correspond to the version of tzdata shipped with the ICU it uses, and they do backport updates to prior Chrome releases within a certain window. Apple has a sideband way of deploying tzdata to all devices that doesn't appear via the normal Software Update mechanism. So it all depends on which particular OS/browser combo you're interested in and the decisions those owners made.
This is why I'm sticking with moment.js for now. I don't like that it's not immutable, but I value bundling timezone data into the app too much. Our customers are likely to use outdated browsers at their workplaces (we even had to maintain IE11 compatibility a bit too long for our liking).
Nice to see Temporal finally landing after such a long standardization process. The duration and timezone handling should simplify a lot of date math that libraries like moment and date-fns have been covering.
TIL temporal_rs was a thing. Not to be biased, but I think it's awesome how much Rust is used in the JS ecosystem. I saw Vite using oxc in some parts. Love it!
Temporal API is fascinating. Time handling has always been painful in programming languages. Curious how widely this will get adopted in production systems.
Maybe, but it's probably the size of momentjs for Temporal and likely still not quite right. It's also not fun at all to have to target a bunch of fills/shims for a specific browser subset, though if you're targeting mobile, you kind of have to target Safari.
Not as bad as IE of old, but still seems to similarly be the odd one out always lagging half a year or more behind.
Yep. You can learn more about why we created this new blog here:
https://bloomberg.github.io/js-blog/post/intro/
I hope you like it ;-)
And if it seems like a surprise, you can blame me for not publicising this kind of content earlier given how long we've been working in this area. Thankfully Jon Kuperman and Thomas Chetwin (plus others) found the time and energy to put this platform together.
Bloomberg has a pretty large software engineering department, including a lot of offshore contractors. Similar to Walmart Labs that does cool stuff as well, despite being part of a retail chain (retail industry typically sees SWEs a cost, not asset).
What surprises you?
Terminal UI is written in JS using Chromium. It’s not just plain Chromium, but it’s still funny that it’s pretty much same approach as universally (according to HN and Reddit) hated Electron.
My playbook for JavaScript dates is.. store in UTC.. exchange only in UTC.. convert to locale date time only in the presentation logic. This has worked well for me enough that Im skeptical of needing anything else
For recording instantaneous events, that's usually sufficient. It's often not enough for scheduling. You can always present UTC or any other zone relative to some other zone, but you need to know that zone. Maybe you're going to a conference in another region and you want to know the time of a talk in that zone because that's more important than your zone. You either need to couple the zone with the time itself, or you need to refer to it. There are good reasons either way. Having an atomic time+zone type is basically trading space for time. When its embedded, you can just use it, which can be better than assuming UTC and then looking up the zone based on, say, the location of the venue.
Storing in UTC is lossy. You've lost information about the event's original UTC offset, at the very least, and probably also its original time zone. Most backends today have good ways to round-trip offset information, and still compare dates easily (as if they were normalized to UTC). Some backends can even round-trip timezone information in addition to offsets.
It's easy not to feel that loss as a big deal, but captured offsets can be very helpful for exactly debugging things like "what time did this user think this was?" versus time zone math (and DST lookups) from UTC. It can help debug cases where the user's own machine had missed a DST jump or was briefly on a different calendar or was traveling.
But a lot of the biggest gains in Temporal are the "Plain" family for "wall clock times"/"wall calendar dates" and breaking them apart as very separate data types. Does a UTC timestamp of "2026-02-01 00:00:00Z" mean midnight specifically and exactly or where you trying to mark "2026-02-01" without a time or timezone. Similarly I've seen data like "0001-01-01 12:10:00Z" mean "12:10" on a clock without the date or timezone being meaningful, but Temporal has a PlainTime for that. You can convert a PlainDate + a PlainTime + a Time Zone to build a ZonedDateTime, but that becomes an explicit process that directly explains what you are trying to do, versus accidentally casting a `Date` intended to be just a wall-clock time and getting a garbage wall-clock date.
That generally works for timestamps (Temporal Instant). But it doesn’t work for representing calendar dates with no time information (Temporal PlainDate) unless you add an additional strict convention like “calendar dates are always represented as midnight UTC”).
I have a scheduling system that allows users to specify recurring events. "Every Monday at 2pm." Which needs to be understood in the native timezone of that user and needs to be capable of being displayed in that timezone for all viewers or optionally in the native timezone of the viewing user.
The only time you need local dates is for scheduling. Stuff like “Report KPIs for each shift. Shifts start at 8:00 local time.”, or “send this report every day at 10:00 local time”, or “this recurring meeting was created by user X while they were in TimeZone Z, make sure meetings follow DST”.
The pathological case with scheduling is: It's 2015. You live in NYC. Your pal in Santiago, Chile says "hey next time you're here let's hang out." You say "great, I have a business trip there next April. Let's have dinner at 7pm on the 15th." They agree. You enter it into your calendar. If you store it as UTC, you're going to show up to dinner at the wrong time—the DST rules changed in between when you talked and when you expected dinner to happen. If you'd stored it as a local time with tzdb name America/Santiago you'd be there at the correct local time.
"Just use UTC" is another, albeit more subtle, falsehood programmers believe about date/time.
It's fine for distributed logging and computer-only usage, but fails in obscure ways once humans, time zones, travel, laws, and/or daylight saving time get involved.
If you're scheduling events for humans, and can't immediately list the reasons your app is an exception to the above, store the time zone to be safe. You probably don't have big data, and nobody will notice the minuscule overhead.
It does work quite well. Sometimes you need a time zone to go with it. It might not be common, but sometimes you need to know the local time in a particular zone, which is not necessarily where the user is. I work on software that works with local times in arbitrary time zones. We submit data in a schema over which we have no control, which must include such local times that may or may not be in the time zone of the server or the current client machine.
Epoch (a/k/a "unix timestamps") are OK when you just need an incrementing relative time. When you start converting them back and forth to real calendar dates, times, with time zones, DST, leap seconds, etc. the dragons start to emerge.
A lesson I learned pretty early on is always use the date-time datatypes and libraries your language or platform gives you. Think very carefully before you roll your own with integer timestamps.
I mean, I guess it's two steps forward and one step back ... but couldn't they have come up with something that was just two steps forward, and none back ... instead of making us write this nightmare all over the place?
I'd argue that `new Date()` returning the current time is a design mistake, and it should at least have been something like `DateTime.now()`. (Especially because it's called a date but it actually returns a timestamp: the footgun potential is large). C#'s date API isn't the best design (otherwise [NodaTime](https://www.nodatime.org/) wouldn't have been necessary) but it at least got some things right: you don't get the current time by doing `new DateTime()`, you get it by referencing `DateTime.UtcNow` for UTC (almost always what you want), or `DateTime.Now` for local time (which is sometimes what you want, but you should always stop and think about whether you really want UTC).
And even with C#'s date API, I've seen errors. For example, a library that formatted datetime strings by merely writing them out and adding a "Z" to the end, assuming that they would always be receiving UTC datetimes — and elsewhere in the code, someone passing `DateTime.Now` to that library. (I'm guessing the dev who wrote that was in the UK and wrote it during winter time, otherwise he would have noticed that the timestamps were coming out wrong. If he was in the US they'd be 4-7 or 5-8 hours wrong depending on whether DST was in effect. But in the UK during winter, local time equals UTC and you might not notice that mistake).
This is another reason why Temporal's API making clear distinctions between the different types, and requiring you to call conversion functions to switch between them, is a good idea. That C# mistake would have been harder (not impossible, people can always misunderstand an API, but harder) if the library had been using Nodatime. And Temporal is based on the same design principles (not identical APIs, just simmilar principles) as Nodatime.
Firstly, I really want this also and am supportive of an opinionated decision to put something at say Temporal.DateTime() that would be logical for developers to use ‘most of the time’.
However my guess is that the spec designers saw this lack of specivity as part of the problem.
A key issue of dates and times is that we use them culturally in day to day use in very imprecise ways and much is inferred from the context of use.
The concepts of zoned time and “wall clock” time are irreducable and it’s likely much code will be improved by forcing the developer to be explicit with the form of time they want to use and need for their particular use case.
I think this is why it’s so explicitly specified right now.
But I agree; I’ve often struggled with how verbose js can be.
Maybe with time (pun intended), more syntactic sugar and shorter conventions can be added to expand what has been an incredible effort to fix deep rooted issues.
I think that it's nice it's explicit that the method returns the current instant, rather than some other zero value.
There's also other methods that return other types, like
const now = Temporal.Now.instant()
which isn't as bad.
One could argue that the ugliness of the API intentionally reveals the ugliness of datetime. It forces you to really think about what you mean when you want "the current date time," which I think is one of the goals of the API.
What counts as a sensible value? The whole point of the library is to be explicitly about what kind of date/time data you're working with, because different kinds of data have to be handled in very different ways.
If they at least had a Temporal.nowlocal() and a Temporal.nowUTC() that returned a ZonedDateTime set to the local and UTC timezones respectively, that would be 95% of what developers need in practice.
I also find it super more complicated and messy than what you can find in another language without proper justification.
Like the Temporal.Instant with the only difference that is now but in nanosecond.
Would have been better to be Now with a suffix to indicate that it is more precise. Or even better, it is just the function you use or parameter that give the precision.
And why Now as the name space? I would expect the opposite, like python, you have something like
Temporal.Date, and from there you get a date of now or a specific time, with or without timezone info, ...
If you give me your background I'll explain in longer terms but in short it's about making the intent clear and anyone who understands s modicum of PL theory understands why what's a constant is so and what's a function is so.
I'm excited for this conversation. If you see someone respond to a developer ergonomics complaint with "If you give me your background I'll explain in longer terms... anyone who understands s modicum of PL theory" you're about to see some legendary bullshit.
I'm one of the volunteer open-source folks (called "proposal champions" in TC39 parlance) who designed the Temporal API. Sorry for the late reply, as you can imagine it's been a busy week for us.
You raise a very important question: why is `Temporal.Now.zonedDateTimeISO()` so verbose? After 10 years of work on Temporal, you can assume that every API design and naming decision has been argued about, often many times. I'll try to summarize the reasoning and history below to explain how we got there.
There's really five questions here. There's no perfect order to answer them because the answers overlap somewhat, so you may want to read to the end until disagreeing. :-) I will have to split this response up into two posts because it's long.
1. Why do we need `Temporal.Now.`? Why not just `Temporal.`?
The TC39 members working on security required us to have a forward-compatible way to override and/or prevent access to information about the local machine. With the current design, a hosting environment can monkey-patch or remove `Temporal.Now`, and regardless of what Temporal changes in the future that local-machine info will still be blocked or overridden. But if we'd spread methods across each Temporal type (e.g. `Temporal.PlainDate.today()`, `Temporal.Instant.now()`) then a new Temporal type added in the future could allow jailbreaking to get local machine info.
This isn't just a security concern. Environments like jest may want to control the local time that tests see. Hosters of JS code like https://convex.dev/ might want to override the local time so that transactions can be re-run deterministically on another node. And so on.
2. Why a `Temporal.*` namespace? Why not just `ZonedDateTime`, `PlainTime`, etc. in the global namespace?
If `Date` didn't exist, we'd probably have done exactly this, and argued harder about (1) above, and we maybe could have won that argument!
But we were worried about the confusion between `Date` and another type named `PlainDate` (or whatever we could have called the date-only type). By putting all Temporal types in a namespace, it was much harder to be confused.
A secondary benefit of a namespace was to expose developers (via autocomplete in editors and browser dev tools) to the full set of types available, so that developers would pick the right type for their use case. But the `Date` conflict was the main reason.
We could have made the types TemporalDate, TemporalTime, etc. but that shaves only one character and violates (1) so there was no chance that would move forward. So we went with a namespace.
3. Why is it `Temporal.Now.zonedDateTimeISO()` not `Temporal.now()`?
As @rmunn and others discuss below, one of the core tenets of Temporal (following in the footsteps of Java, Noda time, Rust, and many others) was that developers must figure out up-front what kind of date/time data they want, and then pick the appropriate Temporal type for that data.
For a canonical example of why this is needed, just think of the thousands (millions?) of times that JS developers or end users have ended up with off-by-one-day errors because `new Date()` reports a different date depending on which time zone you're in, even if all you care about is displaying a date where the time zone is not relevant.
It's a reasonable argument that because `Temporal.ZonedDateTime` represents the superset of all Temporal types, it should occupy a privileged position and should be the default Temporal type for something like `Temporal.now()`. Given that I proposed the initial design of the ZonedDateTime type (https://github.com/tc39/proposal-temporal/pull/700) I'm understandably sympathetic to that point of view!
But there are performance concerns. Accessing the system time zone and calendar not free, nor is the extra 2+ bytes to store them in a `Temporal.ZonedDateTime` implementation compared to a cheaper type like `Temporal.Instant`. This also would have popularized a pattern of calling `Temporal.now().toPlainTime()` which creates two objects vs. just creating the desired type in one call via `Temporal.Now.plainTime()`.
4. Why is it `Temporal.ZonedDateTime` not `Temporal.DateTime`?
This is a fun story. Originally there was no `Temporal.ZonedDateTime`, and the type now called `Temporal.PlainDateTime` was called `Temporal.DateTime`. When we added a Temporal type with a datetime + time zone (its placeholder name was LocalDateTime), we needed to figure out naming for the date+time types so that developers would pick the right one: if they knew the time zone then they should pick one, and if they didn't know the time zone then they should pick the other.
The biggest danger was this: if the zoneless type had been named `Temporal.DateTime`, then developers new to JS would almost certainly use it because it sounds like it should be the default. This exposes programs to subtle time zone bugs that only manifest 2x per year when time zones switch from DST/"Summer Time" to standard time and back again.
I'd seen my previous company take two years (!!!) and thousands of hours of developer time to fix exactly this bug because many years before that our 23-year-old founders didn't realize that `DATETIME` in SQL Server was a zoneless type that would skip or lose an hour twice per year.
I was determined to reduce the chance of the same mistake with Temporal by ensuring that the zoneless type would not (like in SQL Server) look like the default type that everyone should use for date/time data.
Naming is hard! My preference was to use "DateTime" for the zoned type, and an something obviously non-default like "ZonelessDateTime" for the other one. Other champions felt the opposite: that because we were adding a time zone then its name should be longer. Eventually we settled on "Plain*" for all zoneless types and "ZonedDateTime" for the DST-safe one.
5. Why is it `Temporal.Now.zonedDateTimeISO()` not `Temporal.Now.zonedDateTime()`?
I tried. The presence of "ISO" in method names (of `Temporal.Now` and a few other Temporal methods) is my biggest regret in the 6 years I spent working on this proposal. That said, it could have been even worse. Here's some history.
"ISO" in this context refers to the ISO 8601 calendar, as opposed to the Chinese calendar, the Hebrew Calendar, the Coptic calendar, the Persian calendar, one of several Islamic calendars, and of course the Gregorian calendar which is effectively the same as ISO 8601 except the former uses BC/AD eras.
One of the features of Temporal is to support both Gregorian and non-Gregorian calendars. Most of the world's population uses a non-Gregorian calendar for some purposes, like determining holidays or for official government documents. So it's convenient that user can write code like this:
// What's the date of the next Chinese new year?
Temporal.Now.zonedDateTimeISO()
.withCalendar('chinese')
.add({ years: 1 })
.with({ month: 1, day: 1})
.toPlainDate()
.withCalendar('gregory')
.toLocaleString()
// => '2/6/2027'
In 10 years of working on Temporal, the argument that took more hours and frustration was whether we should default to the ISO calendar in Temporal APIs.
One side of this argument was this: in localization, you never want a default locale because then developers won't write or test their code to work in other locales. For languages this is exactly the right approach because there is no default language worldwide that everyone knows. Therefore, we should not have a default calendar in Temporal.
The other side of that argument was this: the Gregorian calendar is used in almost every country in the world for almost all use cases that software will need to handle. Exceptions prove the rule, because the most common use of non-Gregorian calendars in software is building apps that correlate Gregorian with another calendar so that multi-calendar users can see both dates side-by-side. Therefore, we should make era-less Gregorian (called the ISO 8601 calendar in JS) the default calendar in Temporal.
After many hours of discussion, it was clear that neither side could convince the other. So we made a painful compromise: we'd have two variations of APIs. Methods like `Temporal.Now.zonedDateTimeISO()` would use the ISO 8601 calendar by default, and methods like `Temporal.Now.zonedDateTime()` would require the user to provide a calendar or would throw a `RangeError`.
This compromise was not ideal because it would confuse developers who'd call the shorter ISO-less methods and end up with exceptions at runtime. In 2023 we had an opportunity to improve it somewhat, because Temporal had to trim about a third of the surface area of the the proposal (IIRC, about 100 properties and methods!) to address concerns from browser implementers about the RAM and download size impact of so much new code on devices like Apple Watch and low-end Android phones.
As part of that trimming exercise, we decided to remove one of the ISO-default vs. calendar-required method pairs. Thankfully, the ISO-default variant was retained. I lobbied to remove "ISO" from the method names, now that differentiating them from their calendar-required counterparts was not required anymore. This lobbying didn't succeed. See https://github.com/tc39/proposal-temporal/issues/2846 for details.
I'm not happy with the extra `ISO` that millions of developers and AI agents will have to be typing in the decades to come. But in the grand scheme of things this is a small price to pay for a dramatically improved date/time/timezone/calendar API. Building standards is inherently a team sport, and if you're winning every argument then it's probably an unhealthy team. Overall I'm quite happy where we ended up with Temporal, even if some of the decisions didn't match what I thought would be best.
The worst are methods that both mutate and return values.
I know this gets into a complex land of computer science that I don’t understand well, but I wish I could define in TypeScript “any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.” Because I sometimes want to mutate something in a function and return it for convenience and performance reasons, but I want you to have to reason about the returned type and never again touch the original type, even if they are the same object.
> And having used it in rust, I wish more languages had something like that.
Same. I'm at the point where I feel like copy-by-default semantics are one of the ancient original sins of programming languages. Single-ownership is so, so useful, and it's trivial to implement and not at all difficult to understand (especially compared to something like Rust's borrow checker).
> but I wish I could define in TypeScript “any object passed into this function is now typed _never_.
Having explicit language to differentiate between pass by reference and pass by value avoids this confusion. It requires a little more thought from the programmer but it’s really minimal once you internalize it.
Rust takes this a step further with an explicit ownership and borrowing model. The compiler will refuse your code if you try to write something that that violates the borrow checker. This is endlessly frustrating to beginners but after adapting your mind to ownership safety you find yourself thinking in the same way in other languages.
I always found real-world JavaScript codebases frustrating because there was so much sharing that wasn’t entirely intentionally. It only got fixed when someone recognized a bug as a result.
Yeah exactly. That's what I've loved about Rust and hated about real-world JS. I end up having to reason about an entire case that might not be real at all: does this function mutate what I'm passing it? Should I eagerly deep copy my object? UGH.
Single-ownership ("affine types") is a separate concept from a borrow checker. Your language doesn't need a borrow checker (or references at all) to benefit from single-ownership, though it may make some patterns more convenient or efficient.
rust would be pretty unusable without references. affine lambda calculus isn’t even turing complete. however, you’re right that a borrow checker is unnecessary, as uniqueness types (the technical term for types that guarantee single ownership) are implemented in clean and idris without a borrow checker. the borrow checker mainly exists because it dramatically increases the number of valid programs.
Supporting single-ownership in a language doesn't mean you can't have opt-in copyability and/or multiple-ownership. This is how Rust already works, and is independent of the borrow checker.
If we consider a Rust-like language without the borrow checker, it's obviously still Turing-complete. For functions that take references as parameters, instead you would simply pass ownership of the value back to the caller as part of the return value. And for structs that hold references, you would instead have them hold reference-counted handles. The former case is merely less convenient, and the latter case is merely less efficient.
What you are describing is linear (or affine) types in academic parlance, where a value must be used exactly (or at most) once, e.g., being passed to a function or having a method invoked, after which the old value is destroyed and not accessible. Most common examples are prolly move semantics in C++ and Rust.
Because Ruby is a dynamic language which mutates state. That isn't considered wrong or bad in those kinds of languages, just a way to make sure the programmer knows they're doing that. Not every PL tries to live up to the ideals of Haskell.
If you don't want an object mutated in Ruby, you can freeze it.
I don't think they're saying it shouldn't be possible to mutate arguments, just that the ! convention should be enforced. The Ruby runtime could, for instance, automatically freeze all arguments to a function that doesn't end with a !. That way all code that correctly follows the mutation naming convention will continue to work, and any development who doesn't know about it will quickly learn when they try to mutate an argument and get an error. Ideally a helpful error telling them to add the !.
If you want to upset people on the internet tell them that JavaScript is strongly typed, immutable, and everything is passed by value. Which is true. You can change member values though, which is the footgun.
If your friend lives in London it may be useful to have that associated timezone so that you can be sure to message them that day in their timezone. They might better appreciate a message from SF sent on March 10th at 9PM "early that morning in London" than March 11th at 9PM "a day late".
A lot of that gets back to why Temporal adds so many different types, because there are different uses for time zone information and being clear how you shift that information can make a big difference. (A birthday is a PlainDate at rest, but when it is time to send them an ecard you want the ZonedDateTime of the recipient's time zone to find the best time to send it.)
His birthday is always all day. The question is where he is. If he travels to Japan his birthday won't change - even if he was born late at night and thus it would be a different day if he was born in Japan.
The other fun ones are daily recurring events for e.g. taking some medication. You take the last one at 10pm before going to bed. You go on a trip which moves you three hours east. Now your calendar helpfully reminds you to take your meds at 1 am.
Given the ubiquity of react, I think immutability is generally rated pretty appropriately. If anything, I think mutability is under-rated. I mean, it wouldn't be applicable to the domain of Temporal, but sometimes a mutable hash map is a simpler/more performant solution than any of the immutable alternatives.
Yes, you can mutate props. But no, it's probably not going to do what you want if you did it intentionally. If react added Object.freeze() (or deepFreeze) to the component render invoker, everything would be the same, except props would be formally immutable, instead of being only expected to be immutable. But this seems like a distinction without much of a difference, because if you just try to use a pattern like that without having a pretty deep understanding of react internals, it's not going to do what you wanted anyway.
React doesn’t really force you to make your props immutable data. Using mutable data with React is allowed and just as error prone as elsewhere. But certainly you are encouraged to use something like https://immutable-js.com together with React. At least that’s what I used before I discovered ClojureScript.
Well, mutability is the default, and React tries to address some of the problems with mutability. So React being popular as a subecosystem inside a mutable environment isn't really evidence that people are missing out on the benefits of mutability.
Though React is less about immutability and more about uni-directional flow + the idiosyncrasy where you need values that are 'stable' across renders.
Yeah... I pretty early in my career firmly cemented on a couple things with date-times. It's either a date-time + zone/location detail or always seconds from unix epoc or UTC in iso-8601 style (later JSON's adopted default) across the wire. Since most systems and JS convert pretty easily between UTC and local.
Same for storage details. I started using the 8601 style mostly in file/log naming so they always sorted correctly, this kind of carried over into my code use pre-dating JSON spec.
Doing the above saves a lot of headaches... I'd also by convention use a few utility scripts for common formatting and date changes (I use date-fns now mostly), that would always start with dtm = new Date(dtm); before manipulation, returning the cloned dtm.
It is not just in time keeping that mutable shared state is an issue, I have seen problems arising from it elsewhere as well in Python especially, but also in C and C++. Probably because Python is pass by reference implicitly, while C and C++ makes pointers/references more explicit, thus reducing the risk of such errors in the code.
There a few schools of thought about what should be done about it. One is to make (almost) everything immutable and hope it gets optimised away/is fast enough anyway. This is the approach taken by functional languages (and functional style programming in general).
Another approach is what Rust does: make state mutable xor shared. So you can either have mutable state that you own exclusively, or you can have read only state that is shared.
Both approaches are valid and helpful in my experience. As someone working with low level performance critical code, I personally prefer the Rust approach here.
When I write JavaScript, I make as many things immutable as I can. Sometimes it adds verbosity and leads to less efficient computational patterns, but overall I believe I run into far fewer bugs that are hard to make sense of. There are things about the design of Temporal I don't really like, but immutability was a solid move.
What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier.
> What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier.
I think Temporal takes the right approach: toString() is the (mostly) round-trippable ISO format (or close to it) and every other format is accessible by toLocaleString(). In Python terms, it is a bit like formally separating __repl__ and __str__ implementations, respectively. Date's toString() being locale-dependent made it a lot harder to round-trip Date in places like JSON documents if you forgot or missed toISOString().
Temporal's various toLocaleString() functions all take the same Intl.DateTimeFormat constructor parameters, especially its powerful options [1] argument, as Date's own toLocaleString() has had for a long while and has been the preferred approach to locale-aware string formatting.
A lesson I've picked up from what little localization work I've done is to avoid "specific formats" as much as possible. Some user's locale is never going to fit your "specific format" and the more you try to (micro-)manage the output format of your dates the more you are likely to make that user upset or show them a very broken experience. The short/medium/long formats you can get out of Intl.DateTimeFormat/toLocaleString aren't perfect, they are compromises, but they work and users can generally trust them.
(If you are using a specific format for something other than display to a user, maybe consider the standardized ISO format instead. Machine-to-machine communications could definitely use a whole lot fewer "specific formats" and explicit Date parsing. Very few backend languages don't have out-of-the-box support or easy found library support for ISO format today.)
Also no mention of Stephen Colebourne, author of Joda and the JSR-310 spec (the basis of java.time), the one person you should always stop and listen to when he says you are doing something wrong with time.
Alas, this post is not the only time the TC39 people ignored him.
Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context?
It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.
> Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times
I don't know about the guy you're replying to, but I've made many mistakes in my coding life, and some of them more than once. The Date API is written in a way to obfuscate the real complexities of date and time management, so I find it quite easy to imagine someone stepping in the same footgun more than once.
EDIT: oh ew, grandparent comment is a bot. How did you recognize it?
Good luck making sure no one ever uses a “yyyy-mm-dd” string to represent a calendar date in a JSON API, then passes the value to the Date constructor, then formats that Date in a browser. It’s an extremely easy mistake to make without very strict conventions around how calendar dates and timestamps are represented across the entire stack.
This is the most common way this happens in my experience - people naively assume that by giving just a date and not a time surely it wont do timezone conversion, but it does (and even worse that behaviour is not at all consistent between different languages/systems). Oh and fun fact JS parses 'YYYY/MM/DD' (slashes instead of dashes) differently from the dashed format as well...
The 'safe' way that I try to make everyone use for 'wall clock'/'business' dates is 'YYYY-MM-DDT00:00:00' (without the Z) - this unambiguously parses as 'this date in the current timezone' in basically every languages Date type and it's ISO 8601 compliant. However it's still a pain in the ass to keep straight when serializing as the 'default' output is usually a timezone converted UTC string (Z at the end).
I'm very happy about this. The fact that Temporal forces you to actually deal with the inherent complexities of time management (primarily the distinction between an instant and a calendar datetime) makes it incredibly difficult to make the mistakes that Date almost seems designed to cause. It's a bit more verbose, but I'll take writing a handful of extra characters over being called at 3AM to fix a DST related bug any day of the week.
Agreed. We've almost eradicated our usage of JS Date - fixing plenty of bugs along the way, and then I extracted thousands of lines of conversions and formatting from our production app (scheduling focused) into a temporal-fun package to make it Temporal more ergonomic for lots of common cases.
npmjs.com/package/temporal-fun
Word of warning Temporal relies on the Intl API for formatting, and support in Chrome is very limited due to their binary size constraints. As a result, you'll need to polyfill unsupported languages using format.js
There are numerous reports on this being an issue e.g. https://issues.chromium.org/issues/40624456
Thanks for the heads up. Will think on this and will probably just document the polyfill.
That's complete crazy.
Format.js polyfills a lot of stuff that's already supported in modern browsers, and seems to prefer its own polyfills to the native APIs.
Is there any way to force it to only use (and bundle) the polyfills that are needed assuming 2025+ era browsers?
That looks neat although your package is missing a link to the source repository.
Good catch. Will get that added today.
github.com/howie-code/temporal-fun
Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.
That's a great example of the kind of wrong assumption that makes dealing with dates and times so challenging.
Some countries start on a Friday or Saturday and until 2022 Iran could start any day of the week although never at 3AM.
Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.
What you want there is to stop saying "day" and instead say "24 hours." This way the code is correct and you don't need to deal with time weirdness.
No, because if I want something to happen everyday at 12 o'clock, I have to wait for one day, if I wait for 24 hours, I will be off by an hour for half of the year.
Why do you want something to happen everyday at 12 o'clock specifically? If this is truly what you want, sure.
Lunch break reminder popup?
Only if you live in one of the brain dead countries that observe the dst anachronism.
ok, but they still observe it and you still have to deal with it in your code.
our personal convictions don't change that fact.
You seem to assume that a day always has 24 hours. Common (but not only) non-24h day lengths are: - 23 hours - 25 hours - 24 hours 1 second - 23 hours 59 minutes 59 seconds
You could assume that a day isn't exactly 24 hours, but it's close-ish to 24 hours. Nope, not even close.
And that assumes that we can treat an hour as a precise measure of time (we can't). On some systems, even a second is not a precise measure of time (second smearing).
To make things worse, those are "simple" edge cases.
Time is hard. I'm not sure if I can make any statement about time that is true.
I am saying that you shouldn't use day as a unit of time. You should use second, minute, hour, etc, because these have a constant duration. sleep(86400) should reliably make your thread sleep for at least 24 hours.
It depends on the context and the system you’re working with. In some systems, an hour may last 3599, 3600 or 3601 seconds (due to the leap second), a minute may be 59,60 or 61 seconds. Even a second is not always a „true” second.
There’s no single time unit that works for all situations.
Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.
Ramadan is observed from one visual sighting of a crescent moon to the next.
Cloud conditions may prevent sighting and thereby alter the official start of Ramadan for an individual location, and from time-to-time, the start of a country's change in timezone.
> Some countries alter their observance of DST in line with their observance of Ramadan, which means that the time-offset changes aligned with Ramadan.
Only Morocco does this, I believe, and it's not even clear that that's actually official time at this point. In 2018, Morocco abolished DST, but it seems unclear what that means in practice.
I'd love it if someone from Morocco could weigh in on what the actual situation is on the ground. Do people still change their clocks for Ramadan? Would they be annoyed if a website kept Moroccan users on standard time during Ramadan?
Cue a longish article titled 'Falsehoods Programmers Believe About Time'
In this day and age when a natural language query can produce the most AbstractBeanFactoryFactoryBeanFactory boilerplate at the same rate as a much more concise equivalent, does verbosity matter as much?
If you want to understand what is going on at all, then yes, good abstraction layers do matter, and a lot at that. Hashtag cognitive debt.
Sure, but if I can summon up a summary of what’s going on for those abstraction layers in a matter of seconds, I don’t particularly care whether they were overly verbose or not. There’s no world where you can hand me a pile of code and expect me to be able to comprehend it faster than an LLM can walk the stack anymore, even the most beautiful pristine code that would make Linus Torvalds praise you is easier to have an LLM parse it and explain it to you than doing it yourself.
And the LLM doesn’t care. You could hand it a pile of the best code ever and a pile of brainfuck and probably the difference between comprehending one over the other is in the seconds if not milliseconds of compute time.
This works only until it doesn't. The stochastic nature of LLMs will not go away. When you have to fix that bug, but the explanations of the LLM are incorrect (root) cause analysis, and you have to dig into the code yourself, you will regret not having taken more care earlier. I have had numerous scenarios in my latest project, in which the LLMs simply did not get on the right track, when I asked them about some issue I saw with a widget or making a custom widget (Python, tkinter). I don't think it will fare much better when analyzing existing code, because ultimately it does not understand things.
Given the stochastic nature, if I am forced to have to dig into the code because the LLM couldn't figure it out perhaps one out of every 10 times, it's still a huge bonus. Probably it depends on what you are working on. Esoteric COBOL? Erlang? Yeah good luck, you're probably hand steering the thing while the frontier model providers figure out how to train it better. Vanilla-ish Python/Golang/Typescript/Java? I pretty much never have to do that nowadays for things the model is familiar with. If i do have to dig into the code, I've never regretted doing it this way, because 90% of my use cases worked just fine, and in those 90% of use cases I was able to produce working code at 20x the rate of hand writing it if not more. Feels like a huge win to me.
> Whilst Firefox was able to implement Temporal as it was being specced - thanks to the great work of André Bargull (known online as Anba)
It's worth highlighting that André is actually a volunteer contributor who managed to implement the whole thing by themselves.
Considering how prolific anba is, the only way we know he isn't an LLM is because he'd have to be several generations more advanced than the current SOTA. (It is possible that he might be an LLM from a few decades in the future, considering the connection to Temporal.)
anba implemented all of Temporal single-handedly, plus fixed up numerous places in the spec, plus migrated the implementation over some massive changes after other implementers discovered what a monster it all is. The original version of the spec kind of forced two separate internal implementation paths for everything, one for custom calendars and one for the built-in stuff, just to make the built-in one reasonably performant. That was a lot of work to implement, and a lot of work to remove. (I think ptomato shepherded the spec side of that?)
Fortunately, anba knows how to take a break, relaxing occasionally with minor tasks like rewriting large swathes of the JIT code generator to optimize the support on various platforms. He also gets plenty of nutrition, by ingesting entire specs and mind-melding with them.
I feel like those not involved in this space might not realize so much stuff that benefits the entire web/world comes from volunteers like anba and companies outside the usual browser vendors. Whether you’re an individual contributor or you want to push your employer to contribute or let you contribute, the best time to get involved is always now. We owe anba a big one. Thank you!!
[dead]
I went through a similar decade-long fire drill around ISO8601 date parsing in Python.[1] Issue started in 2012, and after about a decade a solution was in the standard library.
[1] https://groups.google.com/g/comp.lang.python/c/Q2w4R89Nq1w
Thank you thank you thank you.
Parsing dates with anything other than fromisoformat feels totally backwards in comparison. We were using ciso8601 until fromisoformat was in the standard library. And now things are incredibly simple and reliable.
A big step in the right direction, but I still don't like the API, here's why: Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic. What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize it easily.
This is not the case for Temporal objects. Also, the temporal objects have functions on them, which, granted, makes it convenient to use, but a pain to pass it over the wire.
I'd clearly prefer a set of pure functions, into which I can pass data-only temporal objects, quite a bit like date-fns did it.
This was an intentional design decision. We wanted to make sure all the temporal types could be serialize/deserializable, but as you mentioned, you couldn't implicitly go back to the object you started with as JSON.parse doesn't support that.
Instead the onus is on the developer to re-create the correct object they need on the other side. I don't believe this is problematic because if you know you're sending a Date, DateTime, MonthDay, YearMonth type from one side, then you know what type to rebuild from the ISO string on the other. Having it be automatic could be an issue if you receive unexpected values and are now dealing with the wrong types.
There is an example here in the docs of a reviver being used for Temporal.Instant https://tc39.es/proposal-temporal/docs/instant.html#toJSON
So it's intentional to make people pass down raw strings versus making the communication safe(er) by default?
There are no date, time or datetime types in JSON, so you'll have to serialise it to a string or an int anyway, and then when deserialising you'll need to identify explicitly which values should be parsed as dates.
Well, you could still have a compound object in JSON, that is output by the Temporal API, and which given as input is guaranteed to result in an equal object it was created/serialized from. This compound object must contain all required infos about timezones and such stuff.
.... we're talking about serialization here. "convert to a raw string" is sort of the name of the game.
It's a string in a well specified string format. That's typically what you want for serialization.
Temporal is typed; but its serialization helpers aren't, because there's no single way to talk about types across serialization. That's functionality a serialization library may choose to provide, but can't really be designed into the language.
You realize that JSON isn't just for JavaScript to JavaScript communication, right? Even if you had a magical format (which doesn't make sense and is a bad idea to attempt to auto-deserialize), it wouldn't work across languages.
If you really want that, it's not very hard to design a pair of functions `mySerialize()`, `myDeserialize()` that's a thin wrapper over `JSON.parse`.
its gotta become bytes somehow
This is a real pain point and I run into the same tension in systems where data crosses serialization boundaries constantly. The prototype-stripping problem you're describing with JSON.parse/stringify is a specific case of a more general issue: rich domain objects don't survive wire transfer without a reconstitution step.
That said, I think the Temporal team made the right call here. Date-time logic is one of those domains where the "bag of data plus free functions" approach leads to subtle bugs because callers forget to pass the right context (calendar system, timezone) to the right function. Binding the operations to the object means the type system can enforce that a PlainDate never accidentally gets treated as a ZonedDateTime. date-fns is great but it can't give you that.
The serialization issue is solvable at the boundary. If you're using tRPC or similar, a thin transform layer that calls Temporal.Whatever.from() on the way in and .toString() on the way out is pretty minimal overhead. Same pattern people use with Decimal types or any value object that doesn't roundtrip through JSON natively. Annoying, sure, but the alternative is giving up the type safety that makes the API worth having in the first place.
Sounds like we need an extended JSON with the express intent of conveying common extended values and rich objects: DateTime instants (with calendar system & timezone), Decimal, BigInt, etc.
I disagree: this is not unlike including the schema in the JSON itself. This should be handled by the apps themselves, since they would have to know what the keys mean regardless.
If you do want the interchange format to be the one deserializing into specific runtime data structures, use YAML. YAML's tag syntax allows you to run arbitrary code inside YAML, which can be used for what you want.
I'm not talking about something arbitrarily extensible or compound values like vectors or lat/lon. Just a few more common data types -- primitive-like values that frequently need to be passed around.
This would probably best exist as a well-known wrapper around JSON itself.
there are a zillion of these "json pro" kind of things: superjson, devalue, capnweb, all with slightly different ideas about how to lower high-level semantics to json's available types. it's so easy to do this kind of thing, its a real https://xkcd.com/927/ situation.
CBOR (Concise Binary Object Representation) has JSON-like semantics with type extension support; with built in type extensions its much easier to get some agreement about registering certain magic type IDs to mean certain things. for example from a random google search for "cbor datetime" https://j-richter.github.io/CBOR/date.html; there's an IANA registry of type IDs: https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml
however, it is binary.
Amazon ION is kind of this?
Few people seem to use it outside of Amazon tho
I think a more practical and compatible approach is to keep json as it is, and use a side channel (e.g. an openapi spec) to convey metadata. Then it is up to the client to decide that a date returned as a string is a date or string, or to create a specific class instead of a generic object
For most situations, I deal with this by keeping dates as strings throughout the app, not objects. They get read from the db as strings, passed around as strings. If I need datetime calculations, I use the language's datetime objects to do it and convert right back to string. Display formatting for users happens at the last moment, in the template.
No-one seems to like this style, but I find it much simpler than converting on db read/write and passing datetime objects around.
It's not that much about type safety. Since TypeScript uses duck typing, a DateTime could not be used as a ZonedDateTime because it'd lack the "timezone" property. The other way around, though, it would work. But I wouldn't even mind that, honestly.
The real drawback of the functional approach is UX, because it's harder to code and you don't get nice auto-complete.
But I'd easily pay that price.
Updating JSON.parse() to automatically create Temporal objects (from what shape of JSON value?) without a custom reviver would be a step too far, in my opinion.
This is effectively no different from Date:
in Temporal:Don’t JavaScript Date instances have the same problem? Date implements toJSON, but when parsing JSON you’ll have to manually identify which string values represent Dates and convert them back to Date instances. The exact same is true of Temporal (e.g. Instant).
And as far as I know, date-fns deals with native Date instances, not “data-only objects.”
The serialization thing is real but I don't think OOP vs functional is the actual issue here. JSON has no date type, period. You JSON.stringify a Date, get an ISO string, and hope whoever's parsing remembers to reconstruct it. Temporal doesn't fix that part, but at least when you do reconstruct you're saying "this is a ZonedDateTime" vs "this is an Instant" instead of everything being one ambiguous Date object.
All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.
That's not what I mean. Even though it is serializable, it's still not the same when you serialize/deserialize it.
For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth.
This is problematic if you use tRPC for example.
You would need to use the `reviver` parameter of `JSON.parse()` to revive your date strings to Temporal objects. As others have said, it's a simple `Temporal.from()`
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Depending on your needs (i.e. how you would otherwise use your output jspn), using the reviver can have a significant impact on performance. JSON.parse itself is hyper-optimized. At the company I work we used the reviver for almost exactly this, but profiling showed that using the reviver had enormous impact on performance. We cut it out, and won in the seconds of performance for some large json's.
Instead of using the reviver you can deserialize as a plain string, then later reassign the property as the type you want. E.g.:
I've been doing this for so long and never knew there was a reviver param, thanks - that is super useful.
Having to provide a complete schema of your json everywhere your json gets parsed negates the advantages of json.
The main advantage of json is that it’s human readable and writable. Beyond that, it has no notion of user created data types so anyone using it has to do custom unmarshalling to get a type apart from sting, number, dict and list.
Even if you don't explicitly provide a schema, you implicitly still have one. The recipient needs to know what you're sending them. Unless maybe you want to start parsing JSON payloads with an LLM.
Most JSON libraries in typed languages require this for data binding to complex types though.
Which is why many developers only use JavaScript Object Notation for JavaScript objects, and only JavaScript objects that can losslessly be written as JSON. Which this proposal explicitly does not support.
{"$temporal_type":"PlainYearMonth","$data":"........"}
> For example `JSON.parse(JSON.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})` won't work, because it misses the prototype and is no longer an instance of Temporal.PlainYearMonth.
I don't know if I'm missing something, but that's exactly how I'd expect it to compose. Does the following do what you wanted your snippet to do?
JSON.stringify and JSON.parse should not be viewed as strict inverses of each other. `JSON.parse(JSON.stringify(x)) = x` is only true for a for a small category of values. That category is even smaller if parsing is happening in a different place than stringification because JSON doesn't specify runtime characteristics. This can lead to things like JSON parsing incorrect in JS because they're too large for JS to represent as a number.This seems more to do with how JSON works than Temporal. There are libraries such as Devalue which will handle this for you
`devalue.parse(devalue.stringify(Temporal.PlainYearMonth.from({year:2026,month:1}))).subtract({ years: 1})`
https://www.npmjs.com/package/devalue
This is also true of JavaScript Date instances, so I’m curious what solution you had that did work with raw JSON stringify and parse.
Would a plain data object be an instance of PlainYearMonth?
If not, that regardless of being plain data or a serialized object with functions, you'd still need to convert it to the type you want.
Then you're talking about changing JSON.parse to start parsing some schema as a type instead of object, which would break compatibility.
The JSON types are string, number, boolean, null, object and array. So how could the suggested code possibly work? Do you want JSON.parse to do arbitrary code execution like Python's pickle?
I'm with you on this. I worked on a big Temporal project briefly and I was really turned off by how much of the codebase was just rote mapping properties from one layer to the next.
> What i mean by this is that all my data is plain JSON and no class instances or objects that have function properties, so that I can serialize/deserialize it easily.
This is known as the "primitive obsession" anti-pattern.
> Especially in JavaScript where I often share a lot of code between the client and the server and therefore also transfer data between them, I like to strictly separate data from logic
Which makes me wonder how it'll look like when interfacing with WASM. Better than Date?
It should still be possible to continue using date-fns (or a similar lib) to suit your preference, right?
yes, sure. probably there will even pop up a functional wrapper around the temporal API occasionally. But would've been nice if it was like this from the start.
Would have been interesting to connect back to Java's own journey to improve its time APIs, with Joda-Time leading into JSR 310, released with Java 8 in 2014. Immutable representations, instants, proper timezone support etc.
Given that the article refers to the "radical proposal" to bring these features to JavaScript came in 2018, surely Java's own solutions had some influence?
I would characterize it more as Joda likely informed Moment.js, which better informed TC39 because it was within the JavaScript ecosystem. As we discussed in plenary today when achieving consensus, every programming language that implements or revamps its date time primitives has the benefit of all the prior art that exists at that instant. TC39 always casts a wide net to canvas what other ecosystems do, but isn't beholden to follow in their footsteps and achieves consensus on what is best for JavaScript. So my view is this more represents what the committee believes is the most complete implementation of such an API that an assembled group of JavaScript experts could design over 9 years and finalize in 2026.
Well said. As a Java programmer who hasn’t touched Temporal yet in JS it is extremely similar to the new Java types like… ZonedDateTime.
It’s not identical. The names of the “Plain” objects make a bit more sense to me than the “Local” names Java chose.
But overall easy to use and a fantastic improvement. I can’t wait to get to use it.
Yep, JavaScript got the bad version from Java too!
https://news.ycombinator.com/item?id=42816135
I'm in the C# world and can attribute most of my understanding about dates and times to Noda (the .NET version of Joda). Shout out to Jon Skeet for maintaining it.
Super happy to see Temporal accepted!
Congrats to all the champions who worked super hard on this for so long! It's been fun working on temporal_rs for the last couple years :)
> Safari (Partial Support in Technology Preview)
Safari confirmed as IE Spiritual successor in 2020+.
Slower to implement new features, but still implementing them, just makes it the new Firefox. IE's larger problem was how popular it had been before it stopped implementing new features. It was like if Google got bored with Chrome and decided to stop all funding on it. People would be stuck on Chrome for years after that investment stopped because of all the Chrome-specific things built around it (Electron, Puppeteer, Selenium, etc and so forth).
Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back". Safari's problems are temporary. Chrome is the new Emperor and IE wasn't bad because it stopped, it was bad because it stopped after being the Emperor for some time. People remember how bad the time was after the Empire crumbled, but it's how IE took so many other things down with it that it is easier to remember the interregnum after IE crumbled than to remember the heyday when "IE-only websites are good enough for business" sounded like a good idea and not a cautionary tale.
The biggest problem with IE from a developer standpoint wasn't the slow feature release cadence, it was that the features it did have worked differently from standards-based browsers. That's very much the position of Safari/WebKit today - code that works across all other engines throws errors in WebKit and often requires substantial changes to resolve.
Safari is also pretty popular on iPhones, in fact it has a full 100% market share. With browser updates tied to the OS, that means millions of devices have those "temporary" problems baked in forever.
When IE was the Emperor it was seen as IE's behaviors were the standards. The perspective at the time was that the other browsers were non-standard. That did get codified into the standards eventually. `* { box-sizing: border-box; }` that is towards the top of almost every "reset.css" is CSS standard for "use the IE box model". XHR was named XmlHttpRequest as an IE quirk and that set the standard we still mostly follow today; `fetch` is a nicer API but we still colloquially call it a part of/relative to/replacement for XHR including various browsers' Dev Tools where to focus on `fetch` requests you click the XHR tab.
Both of those things (and others) became "standards" when IE was moving quickly and breaking things. It took a while for the actual multi-browser standards to catch up. XHR took a few years to show up in non-IE browsers. CSS `box-sizing` wasn't added to the CSS standards until 2012 (11 years after IE6 was released, the "last" version of IE for a long time; five years without a new version). A lot of the web was built easier on those things or better with those things which lead to so many people using IE up to IE6 as their primary browser and so many developers building IE-only websites up to IE6.
Again, as a developer it can be easy to remember the pain of still supporting IE6 in 2005 (five years before tools like `box-sizing` made it a lot easier to support similar CSS for both IE and non-IE browsers, and a year before IE7 finally broke the "IE6 is the last IE" problem). It seems a lot harder to remember why we were still supporting a "dead"/"final" IE6 in 2005 or still supporting a "dead"/"final" IE6 in 2012 when IE10 was fresh and new and very standards compliant (including supporting both `box-sizing` modes) but not yet winning over the crowds of legacy sites: everyone was using IE6 until Microsoft killed it. A lot of things were built for its version of "standards" (many of which were better/easier to develop for versus their contemporary real standards) and couldn't be easily upgraded until the real standards also caught up to how fast IE had been innovating/changing/upgrading the standards.
The risk to the web platform that I think IE represents the most cautionary tale about is relying too much on the browser rushing ahead of the standards, because it could stop at any moment and may take a decade or more for the standards to truly catch back up. Because they did.
If Google decided today to do a "The Browser Company-style pivot" because the Age of AI means that browsers are dead, everything a browser can do should be done through agentic automation, and asked all of the Chrome team to switch to some new agentic harness or accept a soft layoff, how much work would there be to move websites out of being "Chrome-only" or built on top of Chromium? (Which to be further unfair is also sort of what feels like is already left of Microsoft's Edge team working in Chromium today.) It's real easy to imagine that hypothetical, I already named two companies working with Chromium that have just about done exactly that. The hypothetical is not that far from the inside baseball of what happened to IE6 where Microsoft thought browsers were "done" and pivoted the IE team to new roles on "higher priority" Windows work and/or soft layoffs.
We remember the pain of having to support older versions of IE pretty well, but not enough of us seem to remember the pain of how we got to that point and how easy it feels like companies could do that to the web again. Safari lagging current standards is a relatively smaller problem compared to if Chrome gets burnt we suffer another "internet dark age" of supporting ancient browsers for a decade or two due to legacy apps and in turn legacy users that don't or won't upgrade.
(Some would argue that can't happen in the same way that IE did because Chromium is open source and already has many forks. I can't help up but bring up examples like the word "diaspora" and the tale of "the Tower of Babel" that a messy soup of forks that no one can agree on as the new "standard" can be its own slow train wreck disaster.)
> Right now the world needs a lot more Safari and Firefox users complaining about Chrome-only sites and tools than it does people complaining about Safari "holding the web back".
There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing).
> Safari's problems are temporary.
What are you talking about? They've been woefully behind for like a decade. Here's an excellent article on the topic: https://infrequently.org/2023/02/safari-16-4-is-an-admission...
And an entire series: https://infrequently.org/series/browser-choice-must-matter/
> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back (no "quotes" needed, as that's precisely what they're doing).
It's a matter of perspective. The safer perspective is: Safari isn't holding the web back, Chrome is moving too fast. Developers making Chrome-only sites and tools are moving too fast for the safety of web standards/web platform. Where one of the safety factors is "widely available in multiple implementations, not just a single browser".
> > Safari's problems are temporary.
> What are you talking about?
The point is that Safari may be moving slow, but it is still moving. It doesn't have enough users to hold the web back. It isn't "always a decade behind", it 's "a couple years to a couple months behind", depending on which caniuse or MDN Baseline approach you want to take.
There are some things Safari doesn't want to implement, but has registered safety or privacy or coupling reasons behind such things. Firefox is doing the same.
Safari isn't trapping website developers in "old standards forever", it is encouraging developers to use safe, private, stable choices. Chrome is "move fast and sometimes break things". Safari doesn't want to be that. That's useful for the web as a platform to have one or two browsers considering their implementations. It's a good reason to point out "Chrome-only" developers as being "too bleeding edge" (sometimes emphasis on the bleeding) and out of touch with standards and standards processes.
As the links I shared showed in tremendous detail, everything you've said is complete nonsense.
The only well supported and consistent argument I see in those links is that Safari is bad at PWAs. I agree with that. But (timely rant incoming) I also think everyone is currently bad at PWAs. The current ServiceWorker-based approach is brittle and hard to use because it is too low level and too tightly coupled to what seem to be Chrome-specific concerns. The previous manifest.json approach should have never been disabled in Chrome, it should have at least lived side-by-side and let developers vote by their feet, at least until a reasonably equivalent high-level manifest replacement was built.
I was just thinking about this this week because I have a webpage I built with offline capabilities and an excuse coming up where many of the webpage's users will be offline for a week but might have use for the webpage, but I can't easily turn it into a PWA because it was built as an MPA and there's no great high level tools for writing an MPA's ServiceWorker because most of the high level libraries are so (overly) focused on SPAs. I wish I could just put a manifest.json or some sort of zip archive users could download and have it share Local Storage.
I do pin a lot of this on Google engineers. The side effect is Safari is having a hard time implementing these "standards", but the real cause is the "standards" are over-complicated trash that are also hard to develop for. Everyone including the links you sent can see how Apple's App Store moat gives them an incentive to drag their feet on implementing these "standards" and yet no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards that are hard for anyone to use and harder for anyone else to implement is just another way to drag your feet and keep the whole web platform behind, without looking like you are dragging your feet.
It would feel different, too, if the fully declarative manifest.json approach hadn't briefly worked (well) in Edge (Spartan) and Firefox before Google derailed that standards train with "Chrome-first" ServiceWorker complications. Always seemed like one of the reasons that Microsoft just gave up on the web platform because they couldn't keep up with Google's machinations (and conflicts of interest) in Chrome.
It is bizarre that you're "pinning" this on the Chromium engineers - who are essentially the only ones moving the web forward.
The safari feet dragging/obstruction goes far beyond PWAs. The chart on this page is one of many examples showing how consistently far behind Safari is - they've been enormously behind chrome and firefox in coverage of tests for 7+ years. https://wpt.fyi/. And here's an extremely comprehensive article on the topic https://webventures.rejh.nl/blog/2024/history-of-safari-show...
As for standards, here's another detailed series to learn from https://infrequently.org/series/effective-standards-work/. Once again, you have it all backwards. Saying "no one is giving Google enough gruff for the conflict of interest with Google Play's moats and making over-complicated standards" is not only laughable, but just dumb - Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.
Moreover, it is quite clearly an institutional decision to hold back the web, or else they would allow for other browser engines to run on iOS rather than focing them all to be skins on webkit. Again, this is all documented in extreme detail in the articles on that site. If you find it to be still somehow lacking, the author is very open to discussion on bluesky or mastodon (I'd prepare far better though, because what you've said thus far would get eviscerated).
Also bizarre that you are saying that Google Play is somehow at the root of this supposed scheme to make web standards impossible for others to implement. Android is similarly against the web flourishing, but evidently not nearly as powerful in the greater Google enterprise as iphone/app store is in Apple.
As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.
And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.
I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.
If you are actually attempting to communicate in good faith, i can't recommend strongly enough that you read that entire site. And, likewise, read and support the work of Open Web Advocacy. https://open-web-advocacy.org/
> It is bizarre that you're "pinning" this on the Chromium engineers - who are essentially the only ones moving the web forward.
I'm saying this is exactly the problem. If the perception is that only one browser is "moving forward" and the rest are just chasing that moving target, that's not healthy and it is not a standards process. WHATWG has always been at risk of "regulatory capture" by Google or at least Chromium interests. More so than ever there are standards that seems like WHATWG rubber stamped whatever Chrome decided to do without larger consensus work with Safari and Firefox. That's really dangerous for the web platform. (And W3C lost to WHATWG and seems increasingly irrelevant as a standards body for HTML.)
I think we are all very lucky that ECMA hasn't so far shown the same risk and TC-39 (JS) continues to look overall diverse and healthy.
> Google doesn't and, in fact, can't "make standards". Standards are something that comes about through the painful diplomatic process described in those links.
This is why I put standards in quotes in most of that comment. I do think WHATWG has already signed off on Chrome-first things as "standards" that aren't in the sense of multiple robust implementations and a diverse enough number of stakeholders that aren't just using Chromium-derived codebases. I worry WHATWG is at risk of getting worse in this.
> As for MPA PWAs, there's nothing at all stopping you from serving pages from a service worker. There's plenty of valid and accessible ways to precache all the pages that a user might need while offline. Workbox (from Google!) makes it easy, but its also easy to hand-roll.
As very personal experience from building PWAs (and failing to build many more of them): Workbox is bloated and awful to work with and is bad enough at SPAs that trying to feed it an MPA makes me want to scream just thinking about it. Hand-rolling a Service Worker remains a nightmare because the API is awful to work with by hand, which is the whole reason Workbox exists. There's something very wrong with the APIs that right now the only answer seems to be "just use Workbox". That's not healthy for the web platform to be so dependent on a single vendor's tool to get over the hump of using a web API. (Even if that tool is open source. CVEs affect open source like everything else.)
The last time I was serious about PWA development I broke down in tears and switched to Ionic's Capacitor and Electron because browser wrappers are still too much easier than writing a PWA.
I know that isn't just me also anecdotally by the number of Electron apps running on my machine even right now (a bunch) and the number of PWA apps running on my machine (none).
Statistically Service Workers and Workbox are massive failures, and it isn't Apple's fault and it is weird to me claiming that it is entirely Apple's fault. If you don't want to blame Google or at least Chromium engineers, that's fine, we don't have to agree on that. But show me the app with a working PWA ServiceWorker that has a good reliable caching strategy, good offline-first support, and people use that offline-first capability regularly and I'll show you a unicorn. The APIs are terrible, the standards should be better. If we don't want to point fingers at why the current APIs and standards are so awful, can we at least find someone to point a finger at who is actively working to make them better? It doesn't seem to be "Just Use Workbox" Chromium. Who is actually trying to move the offline-first web forward towards pragmatic reality and not just "we support it in theory, with this one JS library, but very few are using it in practice and almost none successfully"?
> And, Microsoft most definitely has not given up on the web platform - they literally adopted and make contributions to chromium. The author of that site literally works at Microsoft now, coaching both internal and external teams on improving their use of the web, as well as contributing to standards.
When Microsoft switched to Chromium they soft laid off a lot of their web platform staff. Chromium Edge's outward development focus seems to be AI and First-Party Coupon Cutting Extensions.
Spartan Edge had ideals and seemed to really believe in the PWA as a first class application platform. For a time, I had a bunch of PWAs as daily use applications in Windows 8 and early 10 (not all of which I built myself, either). That era is certainly gone now. WebView2 is making some inroads in reduce the reliance on Electron by certain types of apps, but WebView2 isn't a PWA platform, it is another end run around it/away from it.
> I dont see any point in continuing this discussion, as you haven't shown even the slightest interest in considering how you're living in some bizarro world.
> If you are actually attempting to communicate in good faith
You've strayed close enough to the realm of ad hominem attacks that I'm going to stop here. It doesn't sound like we are going to ever agree, but certainly not because I'm not debating in "good faith" or living in some "bizarro world". It seems rude to me to imply such accusations. Just because I have a different perspective doesn't make me a bad actor nor prove I have some sort of mental health issues. I may have experienced a different world than you have in my career, but there was nothing "bizarro" or worse about it. Different perspectives should be a joy to engage with, not an affront to ridicule. I'm sorry I couldn't find help you find common ground.
it would, indeed, be great if there were others contributing to the web. Mozilla should be, but they seem to be run by incompetent grifters. Apple could be, but that would be completely against their interests. So we're left with chromium moving the web forward - that's not their fault and its ludicrous that you keep saying it is.
as for service worker, I literally said you dont need workbox. I have done lots of hand-rolled MPA caching. Its dead-simple, so i dont know what complexity you're referring to.
As for the fact that there arent many good pwas out there - people dont bother because iphone is a mess. Your arguments would hold water if apple allowed other browser engines and then pwas still languished.
Even still, there's all sorts of efforts towards offline/local-first. Its a hard problem to solve. But, again, simple MPA caching is not hard. If its a dynamic backend, then that would be much more difficult
> There wouldn't be Chrome-only sites and tools if Safari wasn't holding the web back
Given the number of chrome-only sites that block firefox and not safari i think there are other issues in front end land
I agree. It's also interesting how much that overlaps with "Firefox is an ad blocker" CAPTCHAs/paywalls/ad network complaints.
2026 A.D., still no support for native date pickers in mobile Safari.
Safari for iOS got native date pickers in 2012, and desktop Safari got them in 2021.
> "It was a straight port by Ken Smith (the only code in "Mocha" I didn't write) of Java's Date code from Java to C."
This is funny to me; Java's util.Date was almost certainly a port of C's time.h API!
Can't wait for it to land in the server-side runtimes, really the last thing preventing me from adopting it wholesale.
Deno has had it behind the `--untable-temporal` flag for quite a few Minor versions now and the latest Minor update (because of TC-39's Stage 4 acceptance and V8 itself also marking the API as Stable) removed the requirement for the flag and it is out of the box.
Node 26! Only a matter of time... :)
FWIW, I've been using it server-side via the js-temporal polyfill for some time, no issues.
ooh I'd not seen that yet, will have to take a look.
Try `node --harmony-temporal`
Noticed that converting between certain calendars is not supported. Was that choice intentional?
Converting between solar-based and lunar-based calendars is fraught with potential for ambiguity. The Buddhist calendar is a solar calendar, while the Hebrew calendar is lunar-based. So converting between dates in the Buddhist calendar and the international-standard (ISO 8601) calendar is typically easy (give or take some subtleties I won't go into for reasons of length). But converting between the Hebrew calendar and the ISO 8601 calendar, or the Buddhist calendar, involves figuring out when the new moon will be — and since the lunar cycle is 29 or 30 days, 12 lunar months add up to 354 days. So the lunar calendars, including the Hebrew calendar, typically add a "leap month" every two or three years in order to track the sidereal year.
All of which means there are many potential ambiguities in converting between calendars, and the combinatorial explosion possible means they probably only want you to convert between non-ISO8601 calendars and ISO8601. It would be too easy to get corner cases wrong otherwise and not notice, I'm sure. So to convert a date from Buddhist calender to Hebrew calender, you'd probably have to do Buddhist -> ISO8601, then ISO8601 -> Hebrew. (I haven't had time to test that for myself yet, I'll post a correction if that turns out to be wrong).
I think this is intentional design. Anyway we can convert `Temporal.PlainDate` to other calendars explicitly (I believe explicitness is good here).
Certainly surprising
One of my favorite interview questions is asking a candidate to, piece meal, build a calendar. They start with Julian, and then write converters to and from other calendars. Any calendar can be converted to any other, by going through Julian
I got the idea from the book "calendrical calculations"
They travelled through time (forward, at 1X) by nine years to do this for us. I appreciate it.
The Temporal Cookbook on TC39's site provides examples of how using the new API looks/feels:
https://tc39.es/proposal-temporal/docs/cookbook.html
For example, calc days until a future date: https://tc39.es/proposal-temporal/docs/cookbook.html#how-man...
...or, compare meeting times across timezones: https://tc39.es/proposal-temporal/docs/cookbook.html#book-a-...
I didn't know about https://docs.rs/temporal_rs/latest/temporal_rs/
I wonder if it has a chance to replace chrono and jiff in the rust ecosystem.
Yep, temporal_rs is designed with native Rust use in mind, so you should be able to use temporal_rs directly wherever you'd use jiff or chrono.
That being said, the library is designed to be specification conformant and with EcmaScript implementations in mind. There are some specific API choices made specifically for those clients.
That being said, we are always looking for feedback regarding the native Rust API. So feel free to try temporal_rs out and provide whatever feedback you'd like :)
Maybe I will be able to move away from my custom/minimal DT lib, and ISO-8601 timestamp strings in UTC. JS datetime handling in both Date and Moment are disasters. Rust's Chrono is great. Python's builtin has things I don't like, but is useable. Date and Moment are traps. One of their biggest mistakes is not having dedicated Date and Time types; the accepted reason is "Dates and times don't exist on their own", which is bizarre. So, it's canon to use a datetime (e.g. JS "Date") with 00:00 time, which leads to subtle errors.
From the link, we can see Temporal does have separate Date/Time/Datetime types. ("PlainDate" etc)
I wouldn't be surprised to see the Rust ecosystem eventually move to Temporal's api, given v8 (Chrome) adopted Boa's rust implementation temporal_rs (https://docs.rs/temporal_rs/latest/temporal_rs/), see burntsushi's arguments for the need of a better datetime handling library in Rust (https://github.com/BurntSushi/jiff/blob/master/DESIGN.md#why...). I'm not sure his jiff create will be the one, i think temporal_rs has become the authoritative implementation.
Yes, please try! One of the main motivations for doing all this work is to slim down both the amount of code that has to be delivered and executed by providing everything that's needed by the platform. In addition, you're slimming the potential bug/attack surface as well, which is always nice.
> Higher-precision timestamps (nanoseconds, at a minimum)
I get HFT, but I have a hard time comprehending a need for a Bloomberg Terminal to be talking in picoseconds, as in fractions of a billionth of a second.
I’d like to have interval types for example
That's Duration!
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...At least in java.time (which I believe an inspiration for Temporal) Duration (https://docs.oracle.com/en/java/javase/21/docs/api/java.base...) is a time-based measure of time. For example, 5 hours, 59 minutes, and 15 seconds.
Period (https://docs.oracle.com/en/java/javase/21/docs/api/java.base...) is a date-based measure of time. 2 years, 3 months, and 4 days.
Interval (https://www.threeten.org/threeten-extra/apidocs/org.threeten...) isn't built into java.time, however, it is in the popular threeten-extra library. The docs say "An interval represents the time on the time-line between two Instants." The main difference being that Interval is anchored to the timeline while Duration and Period are not.
It is called Duration.
a much less ambiguous name than Interval
The Java parallel is apt. Joda-Time dominated the ecosystem for about 8 years before JSR 310 landed in Java 8 (2014). One thing that helped there was a clear, single release target.
What I keep thinking about with Temporal is the adoption timeline question isn't really 'is it specced?' anymore, it's 'what minimum runtime version do I need?' Node.js, Deno, Bun all need to ship it stably, and then the practical floor for usage is wherever most prod environments are. The polyfill situation (@js-temporal/polyfill and others) doesn't really collapse until that happens.
So the speccing is done but I think we're still a couple of LTS cycles away from it being genuinely boring to reach for Temporal.
> Developers would often write helper functions that accidently mutated the original Date object in place when they intended to return a new one
It's weird that they picked example code that is extremely non-accidentally doing this.
An example that is hard to follow defeats the point. It's just showing what pattern is possible and you can imagine the abstraction layers and indirection that would make it happen accidentally.
Oh, for a second, TeMPOraL (https://news.ycombinator.com/user?id=TeMPOraL) came to my mind!
Temporal is a good idea, but the API is too complicated for broad adoption:
- new Date() equivalent in Temporal is `const now = Temporal.Now.zonedDateTimeISO();`.
- Date.now() equivalent is `Temporal.Now.instant().epochMilliseconds`
- It’s PascalCase, where JS is mostly snakeCase.
- nanoseconds per default. who needs that except Bloomberg? It should have been an option
It’s definitely great all the efforts put in place, but it’s not going to be a replacement to Date which such a complicated design.
Most of that complication is there because times and dates are actually complicated. You can have a nice simple API that doesn't expose the complication only if you're happy for it to encourage false assumptions and wrong behaviour.
But, still, let's look at your first couple of complaints.
To make #1 more explicit: If you want the equivalent of "new Date()", then as you observe you need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does?
To make #2 more explicit: If you want the equivalent of "Date.now()", then as you observe you again need to say something that's longer because it's more specific about what it's giving you. Why can't it just do the obvious simple thing, like Date does?
Well, because as those two examples show there isn't actually an obvious simple thing. Two operations both of which one might expect to do the obvious simple thing do different things, and if there's some obvious way for someone who doesn't already happen to have the specs of Date memorized to know which one is "new Date()" and which one is "Date.now()", I don't know what it is.
So, to me, those first two examples look like pretty convincing evidence that Temporal is a better design and one that's less likely to lead non-experts to make serious mistakes.
... And then your other two complaints aren't actually about the API being "too complicated" at all! PascalCase isn't more complicated than snakeCase. Nanoseconds aren't more complicated than milliseconds.
(Also: "zonedDateTimeISO" and "epochMilliseconds" are in fact both snakeCase, and a quick look at the Temporal documentation suggests that this is the norm. Method names are snakeCase, class names are PascalCase. I am not a Javascript expert but isn't that pretty normal?)
Thanks for sharing your thoughts too. I still have the feeling that broad adoption comes from simple things that just work. And the complicated stuff is more optional.
It's been a while since I worked in JS but dealing with dates/times, and the lack of real integer types were always two things that frustrated me.
As a side note, huge fan of Promise.allSettled. When that dropped it cleaned up so much of the code I was writing at the time.
Pretty big fan of Temporal. Been using the polyfill for a while. Very nice to use a modern, extremely well thought-through API!
If you were creating a new programming language in 2026, which DateTime/Temporal library would you copy and why?
Bravo to the designers of this library. It’s well implemented and I’ve been using the poly fill for years now
Doesn't the implementation being in rust for many browser (`temporal_rs`) make it possibly slower than it could be in pure JS? Calendar is not very intensive process, so I would not be surprised if the slowness of boundary passing make it slower.
Actually most APIs of JavaScript are implemented in C++ in modern browsers, not in JS. I guess adopting Rust isn't an obstacle for performance.
> have to agree on what "now" means, even when governments change DST rules with very little notice.
I didn't spot how Temporal fixes this. What happens when "now" changes? Does the library get updated and pushed out rapidly via browsers?
Right, browsers own it instead of websites needing to rebuild Moment.js bundles. Additionally, most browsers pass the ownership further to the user's OS as the IANA timezone database is a useful system-level service and best updated at the cadence of OS "required" updates.
I believe V8 / chrome bundles IANA time zones into the zoneinfo64 resource bundle. I'm not actually sure they hit the system tzdb at all.
Typically time zone data is updated in IANA's time zone database. That data would need to be updated in the implementation. In this case, the browser would need to update their time zone data.
Depending on the situation, the data lives either within the browser or within the OS. Chrome releases ship versions of tzdata that correspond to the version of tzdata shipped with the ICU it uses, and they do backport updates to prior Chrome releases within a certain window. Apple has a sideband way of deploying tzdata to all devices that doesn't appear via the normal Software Update mechanism. So it all depends on which particular OS/browser combo you're interested in and the decisions those owners made.
This is why I'm sticking with moment.js for now. I don't like that it's not immutable, but I value bundling timezone data into the app too much. Our customers are likely to use outdated browsers at their workplaces (we even had to maintain IE11 compatibility a bit too long for our liking).
Nice to see Temporal finally landing after such a long standardization process. The duration and timezone handling should simplify a lot of date math that libraries like moment and date-fns have been covering.
A good article and discussion from January:
Date is out, Temporal is in
https://news.ycombinator.com/item?id=46589658
TIL temporal_rs was a thing. Not to be biased, but I think it's awesome how much Rust is used in the JS ecosystem. I saw Vite using oxc in some parts. Love it!
Temporal API is fascinating. Time handling has always been painful in programming languages. Curious how widely this will get adopted in production systems.
No mention of JodaTime?
Thanks for linking to my silly little quiz in the article! :)
Looking at the caniuse results... f*king Safari (and Opera)...
https://caniuse.com/temporal
They've been working on support for a while (years), eg this 2022 commit. https://github.com/WebKit/WebKit/commit/e6717cdeb6a841f4b1f6...
perhaps don't be hard on them, Chrome released this to stable 2 months ago.
I usually am not too harsh on Safari on implementation of new features but this is a bummer, and reflects poorly on them
And I have to support safari while dealing with all the problems that are mentioned in this article. Maybe there is a polyfill.
yes, there's a few different polyfills https://github.com/tc39/proposal-temporal/tree/main/#polyfil...
Probably, but I'm guessing it's as big as moment.js ...
there's plenty of polyfills for every new JS idea on the roadmap
Maybe, but it's probably the size of momentjs for Temporal and likely still not quite right. It's also not fun at all to have to target a bunch of fills/shims for a specific browser subset, though if you're targeting mobile, you kind of have to target Safari.
Not as bad as IE of old, but still seems to similarly be the odd one out always lagging half a year or more behind.
coming from PHP, it's incredible how many times I've been bitten by glitches with managing time with JS clientside.
Temporal is nice but I've tried using it and had terrible performances. Hope the implementations get better in the future.
> The first proposal I worked on was Promise.allSettled, which was fulfilling.
Har har.
Very happy for it finally being there!
Aside: Bloomberg JS blog? ok.
Yep. You can learn more about why we created this new blog here:
I hope you like it ;-)And if it seems like a surprise, you can blame me for not publicising this kind of content earlier given how long we've been working in this area. Thankfully Jon Kuperman and Thomas Chetwin (plus others) found the time and energy to put this platform together.
Bloomberg has a pretty large software engineering department, including a lot of offshore contractors. Similar to Walmart Labs that does cool stuff as well, despite being part of a retail chain (retail industry typically sees SWEs a cost, not asset).
oh, just meant it was a new tech blog from them.
Yes! Brand new!
What surprises you? Terminal UI is written in JS using Chromium. It’s not just plain Chromium, but it’s still funny that it’s pretty much same approach as universally (according to HN and Reddit) hated Electron.
https://youtu.be/uqehwCWKVVw?is=wBijGwdD2k2jIOu7
My playbook for JavaScript dates is.. store in UTC.. exchange only in UTC.. convert to locale date time only in the presentation logic. This has worked well for me enough that Im skeptical of needing anything else
For recording instantaneous events, that's usually sufficient. It's often not enough for scheduling. You can always present UTC or any other zone relative to some other zone, but you need to know that zone. Maybe you're going to a conference in another region and you want to know the time of a talk in that zone because that's more important than your zone. You either need to couple the zone with the time itself, or you need to refer to it. There are good reasons either way. Having an atomic time+zone type is basically trading space for time. When its embedded, you can just use it, which can be better than assuming UTC and then looking up the zone based on, say, the location of the venue.
Storing in UTC is lossy. You've lost information about the event's original UTC offset, at the very least, and probably also its original time zone. Most backends today have good ways to round-trip offset information, and still compare dates easily (as if they were normalized to UTC). Some backends can even round-trip timezone information in addition to offsets.
It's easy not to feel that loss as a big deal, but captured offsets can be very helpful for exactly debugging things like "what time did this user think this was?" versus time zone math (and DST lookups) from UTC. It can help debug cases where the user's own machine had missed a DST jump or was briefly on a different calendar or was traveling.
But a lot of the biggest gains in Temporal are the "Plain" family for "wall clock times"/"wall calendar dates" and breaking them apart as very separate data types. Does a UTC timestamp of "2026-02-01 00:00:00Z" mean midnight specifically and exactly or where you trying to mark "2026-02-01" without a time or timezone. Similarly I've seen data like "0001-01-01 12:10:00Z" mean "12:10" on a clock without the date or timezone being meaningful, but Temporal has a PlainTime for that. You can convert a PlainDate + a PlainTime + a Time Zone to build a ZonedDateTime, but that becomes an explicit process that directly explains what you are trying to do, versus accidentally casting a `Date` intended to be just a wall-clock time and getting a garbage wall-clock date.
That generally works for timestamps (Temporal Instant). But it doesn’t work for representing calendar dates with no time information (Temporal PlainDate) unless you add an additional strict convention like “calendar dates are always represented as midnight UTC”).
I have a scheduling system that allows users to specify recurring events. "Every Monday at 2pm." Which needs to be understood in the native timezone of that user and needs to be capable of being displayed in that timezone for all viewers or optionally in the native timezone of the viewing user.
Temporal is a blessing.
The only time you need local dates is for scheduling. Stuff like “Report KPIs for each shift. Shifts start at 8:00 local time.”, or “send this report every day at 10:00 local time”, or “this recurring meeting was created by user X while they were in TimeZone Z, make sure meetings follow DST”.
Outside of scheduling UTC is the way.
The pathological case with scheduling is: It's 2015. You live in NYC. Your pal in Santiago, Chile says "hey next time you're here let's hang out." You say "great, I have a business trip there next April. Let's have dinner at 7pm on the 15th." They agree. You enter it into your calendar. If you store it as UTC, you're going to show up to dinner at the wrong time—the DST rules changed in between when you talked and when you expected dinner to happen. If you'd stored it as a local time with tzdb name America/Santiago you'd be there at the correct local time.
> Report KPIs for each shift. Shifts start at 8:00 local time.
To represent this you probably don't want a local date. Plain times [1] and plain date/times [2] are a better fit.
[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
"Just use UTC" is another, albeit more subtle, falsehood programmers believe about date/time.
It's fine for distributed logging and computer-only usage, but fails in obscure ways once humans, time zones, travel, laws, and/or daylight saving time get involved.
If you're scheduling events for humans, and can't immediately list the reasons your app is an exception to the above, store the time zone to be safe. You probably don't have big data, and nobody will notice the minuscule overhead.
It does work quite well. Sometimes you need a time zone to go with it. It might not be common, but sometimes you need to know the local time in a particular zone, which is not necessarily where the user is. I work on software that works with local times in arbitrary time zones. We submit data in a schema over which we have no control, which must include such local times that may or may not be in the time zone of the server or the current client machine.
why UTC and not epoch then?
Epoch (a/k/a "unix timestamps") are OK when you just need an incrementing relative time. When you start converting them back and forth to real calendar dates, times, with time zones, DST, leap seconds, etc. the dragons start to emerge.
A lesson I learned pretty early on is always use the date-time datatypes and libraries your language or platform gives you. Think very carefully before you roll your own with integer timestamps.
Same here, this is the way
I thought this Temporal is about the durable execution Temporal, well it is about time...
I wish JavaScript held onto the name Mocha :)
What a journey!
From the article:
The Temporal equivalent is: Dear god, that's so much uglier!I mean, I guess it's two steps forward and one step back ... but couldn't they have come up with something that was just two steps forward, and none back ... instead of making us write this nightmare all over the place?
Why not?
That’s uglier because, if you were previously doing new Date(), you almost certainly don’t want a zonedDateTime. You almost certainly want an Instant.
I'd argue that `new Date()` returning the current time is a design mistake, and it should at least have been something like `DateTime.now()`. (Especially because it's called a date but it actually returns a timestamp: the footgun potential is large). C#'s date API isn't the best design (otherwise [NodaTime](https://www.nodatime.org/) wouldn't have been necessary) but it at least got some things right: you don't get the current time by doing `new DateTime()`, you get it by referencing `DateTime.UtcNow` for UTC (almost always what you want), or `DateTime.Now` for local time (which is sometimes what you want, but you should always stop and think about whether you really want UTC).
And even with C#'s date API, I've seen errors. For example, a library that formatted datetime strings by merely writing them out and adding a "Z" to the end, assuming that they would always be receiving UTC datetimes — and elsewhere in the code, someone passing `DateTime.Now` to that library. (I'm guessing the dev who wrote that was in the UK and wrote it during winter time, otherwise he would have noticed that the timestamps were coming out wrong. If he was in the US they'd be 4-7 or 5-8 hours wrong depending on whether DST was in effect. But in the UK during winter, local time equals UTC and you might not notice that mistake).
This is another reason why Temporal's API making clear distinctions between the different types, and requiring you to call conversion functions to switch between them, is a good idea. That C# mistake would have been harder (not impossible, people can always misunderstand an API, but harder) if the library had been using Nodatime. And Temporal is based on the same design principles (not identical APIs, just simmilar principles) as Nodatime.
Firstly, I really want this also and am supportive of an opinionated decision to put something at say Temporal.DateTime() that would be logical for developers to use ‘most of the time’.
However my guess is that the spec designers saw this lack of specivity as part of the problem.
A key issue of dates and times is that we use them culturally in day to day use in very imprecise ways and much is inferred from the context of use.
The concepts of zoned time and “wall clock” time are irreducable and it’s likely much code will be improved by forcing the developer to be explicit with the form of time they want to use and need for their particular use case.
I think this is why it’s so explicitly specified right now.
But I agree; I’ve often struggled with how verbose js can be.
Maybe with time (pun intended), more syntactic sugar and shorter conventions can be added to expand what has been an incredible effort to fix deep rooted issues.
I think that it's nice it's explicit that the method returns the current instant, rather than some other zero value.
There's also other methods that return other types, like
which isn't as bad.One could argue that the ugliness of the API intentionally reveals the ugliness of datetime. It forces you to really think about what you mean when you want "the current date time," which I think is one of the goals of the API.
What would have been wrong with Temporal.now() returning a sensible value?
What counts as a sensible value? The whole point of the library is to be explicitly about what kind of date/time data you're working with, because different kinds of data have to be handled in very different ways.
If they at least had a Temporal.nowlocal() and a Temporal.nowUTC() that returned a ZonedDateTime set to the local and UTC timezones respectively, that would be 95% of what developers need in practice.
I also find it super more complicated and messy than what you can find in another language without proper justification.
Like the Temporal.Instant with the only difference that is now but in nanosecond. Would have been better to be Now with a suffix to indicate that it is more precise. Or even better, it is just the function you use or parameter that give the precision.
And why Now as the name space? I would expect the opposite, like python, you have something like Temporal.Date, and from there you get a date of now or a specific time, with or without timezone info, ...
If you give me your background I'll explain in longer terms but in short it's about making the intent clear and anyone who understands s modicum of PL theory understands why what's a constant is so and what's a function is so.
I'm a programmer. I'm a human. Perhaps we should also allow for some "human theory" inside our understanding.
I'm excited for this conversation. If you see someone respond to a developer ergonomics complaint with "If you give me your background I'll explain in longer terms... anyone who understands s modicum of PL theory" you're about to see some legendary bullshit.
It's like witnessing a meteor shower!
Or const now = new Temporal();
I'm one of the volunteer open-source folks (called "proposal champions" in TC39 parlance) who designed the Temporal API. Sorry for the late reply, as you can imagine it's been a busy week for us.
You raise a very important question: why is `Temporal.Now.zonedDateTimeISO()` so verbose? After 10 years of work on Temporal, you can assume that every API design and naming decision has been argued about, often many times. I'll try to summarize the reasoning and history below to explain how we got there.
There's really five questions here. There's no perfect order to answer them because the answers overlap somewhat, so you may want to read to the end until disagreeing. :-) I will have to split this response up into two posts because it's long.
1. Why do we need `Temporal.Now.`? Why not just `Temporal.`?
The TC39 members working on security required us to have a forward-compatible way to override and/or prevent access to information about the local machine. With the current design, a hosting environment can monkey-patch or remove `Temporal.Now`, and regardless of what Temporal changes in the future that local-machine info will still be blocked or overridden. But if we'd spread methods across each Temporal type (e.g. `Temporal.PlainDate.today()`, `Temporal.Instant.now()`) then a new Temporal type added in the future could allow jailbreaking to get local machine info.
This isn't just a security concern. Environments like jest may want to control the local time that tests see. Hosters of JS code like https://convex.dev/ might want to override the local time so that transactions can be re-run deterministically on another node. And so on.
2. Why a `Temporal.*` namespace? Why not just `ZonedDateTime`, `PlainTime`, etc. in the global namespace?
If `Date` didn't exist, we'd probably have done exactly this, and argued harder about (1) above, and we maybe could have won that argument!
But we were worried about the confusion between `Date` and another type named `PlainDate` (or whatever we could have called the date-only type). By putting all Temporal types in a namespace, it was much harder to be confused.
A secondary benefit of a namespace was to expose developers (via autocomplete in editors and browser dev tools) to the full set of types available, so that developers would pick the right type for their use case. But the `Date` conflict was the main reason.
We could have made the types TemporalDate, TemporalTime, etc. but that shaves only one character and violates (1) so there was no chance that would move forward. So we went with a namespace.
3. Why is it `Temporal.Now.zonedDateTimeISO()` not `Temporal.now()`?
As @rmunn and others discuss below, one of the core tenets of Temporal (following in the footsteps of Java, Noda time, Rust, and many others) was that developers must figure out up-front what kind of date/time data they want, and then pick the appropriate Temporal type for that data.
For a canonical example of why this is needed, just think of the thousands (millions?) of times that JS developers or end users have ended up with off-by-one-day errors because `new Date()` reports a different date depending on which time zone you're in, even if all you care about is displaying a date where the time zone is not relevant.
It's a reasonable argument that because `Temporal.ZonedDateTime` represents the superset of all Temporal types, it should occupy a privileged position and should be the default Temporal type for something like `Temporal.now()`. Given that I proposed the initial design of the ZonedDateTime type (https://github.com/tc39/proposal-temporal/pull/700) I'm understandably sympathetic to that point of view!
But there are performance concerns. Accessing the system time zone and calendar not free, nor is the extra 2+ bytes to store them in a `Temporal.ZonedDateTime` implementation compared to a cheaper type like `Temporal.Instant`. This also would have popularized a pattern of calling `Temporal.now().toPlainTime()` which creates two objects vs. just creating the desired type in one call via `Temporal.Now.plainTime()`.
(cont'd in next post)
4. Why is it `Temporal.ZonedDateTime` not `Temporal.DateTime`?
This is a fun story. Originally there was no `Temporal.ZonedDateTime`, and the type now called `Temporal.PlainDateTime` was called `Temporal.DateTime`. When we added a Temporal type with a datetime + time zone (its placeholder name was LocalDateTime), we needed to figure out naming for the date+time types so that developers would pick the right one: if they knew the time zone then they should pick one, and if they didn't know the time zone then they should pick the other.
The biggest danger was this: if the zoneless type had been named `Temporal.DateTime`, then developers new to JS would almost certainly use it because it sounds like it should be the default. This exposes programs to subtle time zone bugs that only manifest 2x per year when time zones switch from DST/"Summer Time" to standard time and back again.
I'd seen my previous company take two years (!!!) and thousands of hours of developer time to fix exactly this bug because many years before that our 23-year-old founders didn't realize that `DATETIME` in SQL Server was a zoneless type that would skip or lose an hour twice per year.
I was determined to reduce the chance of the same mistake with Temporal by ensuring that the zoneless type would not (like in SQL Server) look like the default type that everyone should use for date/time data.
Naming is hard! My preference was to use "DateTime" for the zoned type, and an something obviously non-default like "ZonelessDateTime" for the other one. Other champions felt the opposite: that because we were adding a time zone then its name should be longer. Eventually we settled on "Plain*" for all zoneless types and "ZonedDateTime" for the DST-safe one.
You can read 150 comments in https://github.com/tc39/proposal-temporal/issues/707 if you want to understand the arguments made on all sides of this issue.
5. Why is it `Temporal.Now.zonedDateTimeISO()` not `Temporal.Now.zonedDateTime()`?
I tried. The presence of "ISO" in method names (of `Temporal.Now` and a few other Temporal methods) is my biggest regret in the 6 years I spent working on this proposal. That said, it could have been even worse. Here's some history.
"ISO" in this context refers to the ISO 8601 calendar, as opposed to the Chinese calendar, the Hebrew Calendar, the Coptic calendar, the Persian calendar, one of several Islamic calendars, and of course the Gregorian calendar which is effectively the same as ISO 8601 except the former uses BC/AD eras.
One of the features of Temporal is to support both Gregorian and non-Gregorian calendars. Most of the world's population uses a non-Gregorian calendar for some purposes, like determining holidays or for official government documents. So it's convenient that user can write code like this:
// What's the date of the next Chinese new year? Temporal.Now.zonedDateTimeISO() .withCalendar('chinese') .add({ years: 1 }) .with({ month: 1, day: 1}) .toPlainDate() .withCalendar('gregory') .toLocaleString() // => '2/6/2027'
In 10 years of working on Temporal, the argument that took more hours and frustration was whether we should default to the ISO calendar in Temporal APIs.
One side of this argument was this: in localization, you never want a default locale because then developers won't write or test their code to work in other locales. For languages this is exactly the right approach because there is no default language worldwide that everyone knows. Therefore, we should not have a default calendar in Temporal.
The other side of that argument was this: the Gregorian calendar is used in almost every country in the world for almost all use cases that software will need to handle. Exceptions prove the rule, because the most common use of non-Gregorian calendars in software is building apps that correlate Gregorian with another calendar so that multi-calendar users can see both dates side-by-side. Therefore, we should make era-less Gregorian (called the ISO 8601 calendar in JS) the default calendar in Temporal.
After many hours of discussion, it was clear that neither side could convince the other. So we made a painful compromise: we'd have two variations of APIs. Methods like `Temporal.Now.zonedDateTimeISO()` would use the ISO 8601 calendar by default, and methods like `Temporal.Now.zonedDateTime()` would require the user to provide a calendar or would throw a `RangeError`.
This compromise was not ideal because it would confuse developers who'd call the shorter ISO-less methods and end up with exceptions at runtime. In 2023 we had an opportunity to improve it somewhat, because Temporal had to trim about a third of the surface area of the the proposal (IIRC, about 100 properties and methods!) to address concerns from browser implementers about the RAM and download size impact of so much new code on devices like Apple Watch and low-end Android phones.
As part of that trimming exercise, we decided to remove one of the ISO-default vs. calendar-required method pairs. Thankfully, the ISO-default variant was retained. I lobbied to remove "ISO" from the method names, now that differentiating them from their calendar-required counterparts was not required anymore. This lobbying didn't succeed. See https://github.com/tc39/proposal-temporal/issues/2846 for details.
I'm not happy with the extra `ISO` that millions of developers and AI agents will have to be typing in the decades to come. But in the grand scheme of things this is a small price to pay for a dramatically improved date/time/timezone/calendar API. Building standards is inherently a team sport, and if you're winning every argument then it's probably an unhealthy team. Overall I'm quite happy where we ended up with Temporal, even if some of the decisions didn't match what I thought would be best.
Anyway, I hope this background is useful context.
so Temporal is copying cpp's std::chrono?
More like a copy of Java’s JSR310, which in turn took many years to get right.
interesting point about immutability
And yet another modernisation of the web platform sabotaged by Apple and their misguided (malicious?) refusal to update their devices continually.
https://caniuse.com/temporal
It will take years until this can be widely used as intended.
The spec hasn't even reached stage 4 yet. Chrome only added support 58 days ago. Safari already added support in their alphas.
Sure and that’s nice going forward. Yet unlike with Chrome, older devices won’t be updated making this a nice add-on at best.
I checked and you're mostly incorrect.
2018+ Macs/iPhones still receive Safari updates, with security updates going further back.
Chrome is Android 10+, which requires a device not older than 2017/2018 as well.
Chrome is Windows 10+, which I'd say requires 2015+ hardware.
The difference is not that large, how many devices older than 9 years do you use?
The specification reached stage 4 just yesterday. That was the motive behind the blog post :)
[flagged]
The worst are methods that both mutate and return values.
I know this gets into a complex land of computer science that I don’t understand well, but I wish I could define in TypeScript “any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.” Because I sometimes want to mutate something in a function and return it for convenience and performance reasons, but I want you to have to reason about the returned type and never again touch the original type, even if they are the same object.
> any object passed into this function is now typed _never_. You’ve destroyed it and can’t use it after this.
That is basically what affine types are. Once the value is "consumed" it can't be used again.
In rust, this is expressed as passing an "owned" value to a function. Once you pass ownership, you can't use that value anymore.
And having used it in rust, I wish more languages had something like that.
> And having used it in rust, I wish more languages had something like that.
Same. I'm at the point where I feel like copy-by-default semantics are one of the ancient original sins of programming languages. Single-ownership is so, so useful, and it's trivial to implement and not at all difficult to understand (especially compared to something like Rust's borrow checker).
> but I wish I could define in TypeScript “any object passed into this function is now typed _never_.
Having explicit language to differentiate between pass by reference and pass by value avoids this confusion. It requires a little more thought from the programmer but it’s really minimal once you internalize it.
Rust takes this a step further with an explicit ownership and borrowing model. The compiler will refuse your code if you try to write something that that violates the borrow checker. This is endlessly frustrating to beginners but after adapting your mind to ownership safety you find yourself thinking in the same way in other languages.
I always found real-world JavaScript codebases frustrating because there was so much sharing that wasn’t entirely intentionally. It only got fixed when someone recognized a bug as a result.
Yeah exactly. That's what I've loved about Rust and hated about real-world JS. I end up having to reason about an entire case that might not be real at all: does this function mutate what I'm passing it? Should I eagerly deep copy my object? UGH.
Just call "Object.freeze()" before "return" in your function.
That only goes one level deep so it’s not much of a guarantee
Rust ownership model ("stacked borrows" I believe it's called) is basically this
Single-ownership ("affine types") is a separate concept from a borrow checker. Your language doesn't need a borrow checker (or references at all) to benefit from single-ownership, though it may make some patterns more convenient or efficient.
rust would be pretty unusable without references. affine lambda calculus isn’t even turing complete. however, you’re right that a borrow checker is unnecessary, as uniqueness types (the technical term for types that guarantee single ownership) are implemented in clean and idris without a borrow checker. the borrow checker mainly exists because it dramatically increases the number of valid programs.
Supporting single-ownership in a language doesn't mean you can't have opt-in copyability and/or multiple-ownership. This is how Rust already works, and is independent of the borrow checker.
If we consider a Rust-like language without the borrow checker, it's obviously still Turing-complete. For functions that take references as parameters, instead you would simply pass ownership of the value back to the caller as part of the return value. And for structs that hold references, you would instead have them hold reference-counted handles. The former case is merely less convenient, and the latter case is merely less efficient.
Actually there's tree borrows now. https://www.ralfj.de/blog/2023/06/02/tree-borrows.html
I think it's the other way around - he's projecting rust as what he wants
What you are describing is linear (or affine) types in academic parlance, where a value must be used exactly (or at most) once, e.g., being passed to a function or having a method invoked, after which the old value is destroyed and not accessible. Most common examples are prolly move semantics in C++ and Rust.
ruby has the convention of ! for dangerous destructive or mutating methods. This is something that I wish would spread around a bit.
For example:
# Original array
array = [1, 2, 3]
# Using map (non-destructive)
new_array = array.map { |x| x * 2 }
# new_array is [2, 4, 6]
# array is still [1, 2, 3] (unchanged)
# Using map! (destructive)
array.map! { |x| x * 2 }
# array is now [2, 4, 6] (modified in-place)
> convention
Is the keyword. Anything that should never be broken isn’t a convention. There’s no better convention than compiler error.
Because Ruby is a dynamic language which mutates state. That isn't considered wrong or bad in those kinds of languages, just a way to make sure the programmer knows they're doing that. Not every PL tries to live up to the ideals of Haskell.
If you don't want an object mutated in Ruby, you can freeze it.
I don't think they're saying it shouldn't be possible to mutate arguments, just that the ! convention should be enforced. The Ruby runtime could, for instance, automatically freeze all arguments to a function that doesn't end with a !. That way all code that correctly follows the mutation naming convention will continue to work, and any development who doesn't know about it will quickly learn when they try to mutate an argument and get an error. Ideally a helpful error telling them to add the !.
That's really interesting. Although my worry is the freezing having bad effects down the line after the function returns.
Now, if you could temporarily freeze, and then unfreeze only the ones you froze, that could be really cool.> Now, if you could temporarily freeze, and then unfreeze only the ones you froze, that could be really cool.
Is that a missing feature in Ruby? You can't have a frozen reference to an object while retaining unfrozen ones in another scope? That's too bad.
Yeah, in my testing freeze mutates the object itself to a permanent frozen state.
> The worst are methods that both mutate and return values
Been bitten a few times by Array.sort().
Luckily there’s Array.toSorted() now.
This is possible with the asserts x is y pattern no?
https://www.typescriptlang.org/play/?#code/C4TwDgpgBAYg9nKBe...
I think the sticking points are:
1. You cannot return anything (say an immutable result that has consumed the input)
Okay, so don't return anything, just mutate the original. Except:
2. You cannot mutate the original, return nothing, but the mutated original isn't a subset of the original. For example: https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABB...
Hmm, I see, yes it's quite limited.
If you want to upset people on the internet tell them that JavaScript is strongly typed, immutable, and everything is passed by value. Which is true. You can change member values though, which is the footgun.
These LLM spambots are getting so good they're at the top of many discussions now, and people are none the wiser. Sad, but it was predictable.
Please look into its comment history and flag this. Not that it will solve anything.
I hear you, but this also affects the good discussion below it.
> The other half come from the implicit local timezone conversion in the Date constructor.
Outlook at that issue even in their old C++ (I think) version.
You're in London, you save your friend's birthday as March 11th.
You're now in SF. When is your friend's birthday? It's still all-day March 11th, not March 10th, starting at 5PM, and ending March 11th at 5PM.
If your friend lives in London it may be useful to have that associated timezone so that you can be sure to message them that day in their timezone. They might better appreciate a message from SF sent on March 10th at 9PM "early that morning in London" than March 11th at 9PM "a day late".
A lot of that gets back to why Temporal adds so many different types, because there are different uses for time zone information and being clear how you shift that information can make a big difference. (A birthday is a PlainDate at rest, but when it is time to send them an ecard you want the ZonedDateTime of the recipient's time zone to find the best time to send it.)
His birthday is always all day. The question is where he is. If he travels to Japan his birthday won't change - even if he was born late at night and thus it would be a different day if he was born in Japan.
The other fun ones are daily recurring events for e.g. taking some medication. You take the last one at 10pm before going to bed. You go on a trip which moves you three hours east. Now your calendar helpfully reminds you to take your meds at 1 am.
Immutability is underrated in general. It's a sore point every time I have to handle non-clojure code.
Given the ubiquity of react, I think immutability is generally rated pretty appropriately. If anything, I think mutability is under-rated. I mean, it wouldn't be applicable to the domain of Temporal, but sometimes a mutable hash map is a simpler/more performant solution than any of the immutable alternatives.
Props data passed to React itself isn't immutable which is probably one of the missing bricks.
React only checks references but since the objects aren't immutable they could have changed even without the reference changing.
Immutability also has a performance price which is not always great.
Yes, you can mutate props. But no, it's probably not going to do what you want if you did it intentionally. If react added Object.freeze() (or deepFreeze) to the component render invoker, everything would be the same, except props would be formally immutable, instead of being only expected to be immutable. But this seems like a distinction without much of a difference, because if you just try to use a pattern like that without having a pretty deep understanding of react internals, it's not going to do what you wanted anyway.
React doesn’t really force you to make your props immutable data. Using mutable data with React is allowed and just as error prone as elsewhere. But certainly you are encouraged to use something like https://immutable-js.com together with React. At least that’s what I used before I discovered ClojureScript.
Well, mutability is the default, and React tries to address some of the problems with mutability. So React being popular as a subecosystem inside a mutable environment isn't really evidence that people are missing out on the benefits of mutability.
Though React is less about immutability and more about uni-directional flow + the idiosyncrasy where you need values that are 'stable' across renders.
[flagged]
Yeah... I pretty early in my career firmly cemented on a couple things with date-times. It's either a date-time + zone/location detail or always seconds from unix epoc or UTC in iso-8601 style (later JSON's adopted default) across the wire. Since most systems and JS convert pretty easily between UTC and local.
Same for storage details. I started using the 8601 style mostly in file/log naming so they always sorted correctly, this kind of carried over into my code use pre-dating JSON spec.
Doing the above saves a lot of headaches... I'd also by convention use a few utility scripts for common formatting and date changes (I use date-fns now mostly), that would always start with dtm = new Date(dtm); before manipulation, returning the cloned dtm.
It is not just in time keeping that mutable shared state is an issue, I have seen problems arising from it elsewhere as well in Python especially, but also in C and C++. Probably because Python is pass by reference implicitly, while C and C++ makes pointers/references more explicit, thus reducing the risk of such errors in the code.
There a few schools of thought about what should be done about it. One is to make (almost) everything immutable and hope it gets optimised away/is fast enough anyway. This is the approach taken by functional languages (and functional style programming in general).
Another approach is what Rust does: make state mutable xor shared. So you can either have mutable state that you own exclusively, or you can have read only state that is shared.
Both approaches are valid and helpful in my experience. As someone working with low level performance critical code, I personally prefer the Rust approach here.
One of the first things I learnt to appreciate in C++ already during its C++ARM days was the ability to model mutability.
Naturally there are other languages that do it much better.
The problem is that it still isn't widespread enough.
When I write JavaScript, I make as many things immutable as I can. Sometimes it adds verbosity and leads to less efficient computational patterns, but overall I believe I run into far fewer bugs that are hard to make sense of. There are things about the design of Temporal I don't really like, but immutability was a solid move.
What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier.
> What I don't understand is why they had to make string formatting so rigid. Maybe it has to do with internationalization? I'd have liked if it included a sort of templating system to make the construction of rendered date-time strings much easier.
I think Temporal takes the right approach: toString() is the (mostly) round-trippable ISO format (or close to it) and every other format is accessible by toLocaleString(). In Python terms, it is a bit like formally separating __repl__ and __str__ implementations, respectively. Date's toString() being locale-dependent made it a lot harder to round-trip Date in places like JSON documents if you forgot or missed toISOString().
Temporal's various toLocaleString() functions all take the same Intl.DateTimeFormat constructor parameters, especially its powerful options [1] argument, as Date's own toLocaleString() has had for a long while and has been the preferred approach to locale-aware string formatting.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
The problem is that sometimes you want a very specific format, not a locale-based format. This currently still has to be implemented in userland [1].
[1] https://github.com/js-temporal/proposal-temporal-v2/issues/5
A lesson I've picked up from what little localization work I've done is to avoid "specific formats" as much as possible. Some user's locale is never going to fit your "specific format" and the more you try to (micro-)manage the output format of your dates the more you are likely to make that user upset or show them a very broken experience. The short/medium/long formats you can get out of Intl.DateTimeFormat/toLocaleString aren't perfect, they are compromises, but they work and users can generally trust them.
(If you are using a specific format for something other than display to a user, maybe consider the standardized ISO format instead. Machine-to-machine communications could definitely use a whole lot fewer "specific formats" and explicit Date parsing. Very few backend languages don't have out-of-the-box support or easy found library support for ISO format today.)
I remember the first time I got in touch with Elixir and immutability as a core principle. It changed the way I wrote JavaScript since
[flagged]
They seem to have taken it from Joda time that revolutionized time in java 10+ years ago. Sadly no mention of Joda.
Also no mention of Stephen Colebourne, author of Joda and the JSR-310 spec (the basis of java.time), the one person you should always stop and listen to when he says you are doing something wrong with time.
Alas, this post is not the only time the TC39 people ignored him.
I think that actually may be the MOST appreciated design decision in Temporal ;) either way, I'm also a big fan
Flagged because account is bot operated (posted again 2h40m later with same general comment)
Good. Now someone has to fix JavaScript.
[flagged]
Your bot messed up and posted twice in the same thread.
[flagged]
ai;dr
[flagged]
[dead]
[flagged]
[dead]
[flagged]
[flagged]
Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times. The docs for JS time are pretty minimal and it’s clear it only stores UTC epoch, so why would you assume it can handle “wall clock time” with no other context?
It doesn’t matter if it’s python or tsql or JS or perl — you read the docs on the date time impl every time.
> Assuming this isn’t an LLM bot, I don’t see how you ship that bug multiple times
I don't know about the guy you're replying to, but I've made many mistakes in my coding life, and some of them more than once. The Date API is written in a way to obfuscate the real complexities of date and time management, so I find it quite easy to imagine someone stepping in the same footgun more than once.
EDIT: oh ew, grandparent comment is a bot. How did you recognize it?
They do seem to be an LLM bot from comment history
Good luck making sure no one ever uses a “yyyy-mm-dd” string to represent a calendar date in a JSON API, then passes the value to the Date constructor, then formats that Date in a browser. It’s an extremely easy mistake to make without very strict conventions around how calendar dates and timestamps are represented across the entire stack.
This is the most common way this happens in my experience - people naively assume that by giving just a date and not a time surely it wont do timezone conversion, but it does (and even worse that behaviour is not at all consistent between different languages/systems). Oh and fun fact JS parses 'YYYY/MM/DD' (slashes instead of dashes) differently from the dashed format as well...
The 'safe' way that I try to make everyone use for 'wall clock'/'business' dates is 'YYYY-MM-DDT00:00:00' (without the Z) - this unambiguously parses as 'this date in the current timezone' in basically every languages Date type and it's ISO 8601 compliant. However it's still a pain in the ass to keep straight when serializing as the 'default' output is usually a timezone converted UTC string (Z at the end).
You clearly haven't worked on codebases with other developers
[flagged]