22 ms·

Temporal: The 9-year journey to fix time in JavaScript

790 points by robpalmer 6mo ago

tracker1 6mo ago
Looking at the caniuse results... f*king Safari (and Opera)... https://caniuse.com/temporal https://caniuse.com/temporal
- agos 6mo ago
  I usually am not too harsh on Safari on implementation of new features but this is a bummer, and reflects poorly on them
- beezlewax 6mo ago
  And I have to support safari while dealing with all the problems that are mentioned in this article. Maybe there is a polyfill.
  - jitl 6mo ago
    yes, there's a few different polyfills https://github.com/tc39/proposal-temporal/tree/main/#polyfills https://github.com/tc39/proposal-temporal/tree/main/#polyfil...
  - tracker1 6mo ago
    Probably, but I'm guessing it's as big as moment.js ...
- dmix 6mo ago
  there's plenty of polyfills for every new JS idea on the roadmap
  - tracker1 6mo ago
    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.
- deleted 6mo ago
  [deleted]
- jitl 6mo ago
  They've been working on support for a while (years), eg this 2022 commit. https://github.com/WebKit/WebKit/commit/e6717cdeb6a841f4b1f6b9d8d3b0dec947850abe https://github.com/WebKit/WebKit/commit/e6717cdeb6a841f4b1f6... perhaps don't be hard on them, Chrome released this to stable 2 months ago.
jon_kuperman 6mo ago
What a journey!
normie3000 6mo ago
No mention of JodaTime?
bnb 6mo ago
Can't wait for it to land in the server-side runtimes, really the last thing preventing me from adopting it wholesale.
- apaprocki 6mo ago
  Node 26! Only a matter of time... :)
- CharlesW 6mo ago
  FWIW, I've been using it server-side via the js-temporal polyfill for some time, no issues.
  - bnb 6mo ago
    ooh I'd not seen that yet, will have to take a look.
- WorldMaker 6mo ago
  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.
- ivankra 6mo ago
  Try `node --harmony-temporal`
samwho 6mo ago
Thanks for linking to my silly little quiz in the article! :)
patchnull 6mo ago
[flagged]
- virgil_disgr4ce 6mo ago
  I think that actually may be the MOST appreciated design decision in Temporal ;) either way, I'm also a big fan
- ndr 6mo ago
  Immutability is underrated in general. It's a sore point every time I have to handle non-clojure code.
  - recursive 6mo ago
    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.
    - LunaSea 6mo ago
      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.
      - recursive 6mo ago
        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.
virgil_disgr4ce 6mo ago
Pretty big fan of Temporal. Been using the polyfill for a while. Very nice to use a modern, extremely well thought-through API!
sharktheone 6mo ago
Very happy for it finally being there!
nekevss 6mo ago
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 :)
plucas 6mo ago
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?
- apaprocki 6mo ago
  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.
  - MBCook 6mo ago
    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.
- mrkeen 6mo ago
  Yep, JavaScript got the bad version from Java too! https://news.ycombinator.com/item?id=42816135 https://news.ycombinator.com/item?id=42816135
- mexicocitinluez 6mo ago
  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.
zvqcMMV6Zcr 6mo ago
> Safari (Partial Support in Technology Preview) Safari confirmed as IE Spiritual successor in 2020+.
- cubefox 6mo ago
  2026 A.D., still no support for native date pickers in mobile Safari.
  - CharlesW 6mo ago
    Safari for iOS got native date pickers in 2012, and desktop Safari got them in 2021.
- WorldMaker 6mo ago
  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.
  - nchmy 6mo ago
    > 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/ https://infrequently.org/2023/02/safari-16-4-is-an-admission... And an entire series: https://infrequently.org/series/browser-choice-must-matter/ https://infrequently.org/series/browser-choice-must-matter/
redbell 6mo ago
Oh, for a second, TeMPOraL (https://news.ycombinator.com/user?id=TeMPOraL https://news.ycombinator.com/user?id=TeMPOraL) came to my mind!
ChrisArchitect 6mo ago
A good article and discussion from January: Date is out, Temporal is in https://news.ycombinator.com/item?id=46589658 https://news.ycombinator.com/item?id=46589658
ChrisArchitect 6mo ago
Aside: Bloomberg JS blog? ok.
- deepsun 6mo ago
  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).
  - ChrisArchitect 6mo ago
    oh, just meant it was a new tech blog from them.
    - jon_kuperman 6mo ago
      Yes! Brand new!
- wiseowise 6mo ago
  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 https://youtu.be/uqehwCWKVVw?is=wBijGwdD2k2jIOu7
- robpalmer 6mo ago
  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.
philipallstar 6mo ago
> 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?
- nekevss 6mo ago
  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.
- WorldMaker 6mo ago
  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.
  - nekevss 6mo ago
    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.
- apaprocki 6mo ago
  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.
- Anonyneko 6mo ago
  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).
VanCoding 6mo ago
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.
- qcoret 6mo ago
  All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.
  - VanCoding 6mo ago
    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.
    - gowld 6mo ago
      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.
    - flyingmeteor 6mo ago
      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/Reference/Global_Objects/JSON/parse https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
hungryhobbit 6mo ago
From the article: const now = new Date(); The Temporal equivalent is: const now = Temporal.Now.zonedDateTimeISO(); 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? const now = DateTime();
- sourcegrift 6mo ago
  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.
  - themafia 6mo ago
    I'm a programmer. I'm a human. Perhaps we should also allow for some "human theory" inside our understanding.
  - Bratmon 6mo ago
    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!
- evolve2k 6mo ago
  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.
darepublic 6mo ago
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
- lpa22 6mo ago
  Same here, this is the way
- NooneAtAll3 6mo ago
  why UTC and not epoch then?
  - SoftTalker 6mo ago
    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.
- andrewl-hn 6mo ago
  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.
  - masfuerte 6mo ago
    > 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/Reference/Global_Objects/Temporal/PlainTime https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/PlainDateTime https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
newzino 6mo ago
[flagged]
kemayo 6mo ago
> 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.
- Griffinsauce 6mo ago
  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.
aplomb1026 6mo ago
[flagged]
wpollock 6mo ago
> "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!
NooneAtAll3 6mo ago
so Temporal is copying cpp's std::chrono?
- andrewl-hn 6mo ago
  More like a copy of Java’s JSR310, which in turn took many years to get right.
SoftTalker 6mo ago
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.
xp84 6mo ago
They travelled through time (forward, at 1X) by nine years to do this for us. I appreciate it.
ilovesamaltman 6mo ago
[flagged]
johncomposed 6mo ago
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.
the__alchemist 6mo ago
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)
- apaprocki 6mo ago
  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.
- jitl 6mo ago
  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/ 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-build-another-datetime-library 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.
julius_eth_dev 6mo ago
[flagged]
- cityofdelusion 6mo ago
  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.
  - SchemaLoad 6mo ago
    They do seem to be an LLM bot from comment history
  - tshaddox 6mo ago
    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.
    - p1necone 6mo ago
      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).
  - 6mo ago
patchnull 6mo ago
[flagged]
ventuss_ovo 6mo ago
interesting point about immutability
patchnull 6mo ago
[flagged]
- sharifhsn 6mo ago
  Your bot messed up and posted twice in the same thread.
alanning 6mo ago
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 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-many-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-meeting-across-time-zones https://tc39.es/proposal-temporal/docs/cookbook.html#book-a-...
kemitchell 6mo ago
> The first proposal I worked on was Promise.allSettled, which was fulfilling. Har har.
Animats 6mo ago
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 https://groups.google.com/g/comp.lang.python/c/Q2w4R89Nq1w
- baliex 6mo ago
  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.
Vinnl 6mo ago
> 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.
- sfink 6mo ago
  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.
  - apaprocki 6mo ago
    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!!
  - sieabahlpark 6mo ago
    [dead]
bpiroman 6mo ago
I wish JavaScript held onto the name Mocha :)
tmpfile 6mo ago
I’d like to have interval types for example const D = new Temporal() const t = new Interval({minutes:5}) const v = D.add(t)
- nikeee 6mo ago
  It is called Duration.
  - jitl 6mo ago
    a much less ambiguous name than Interval
- plastic041 6mo ago
  That's Duration! const D = Temporal.PlainDate.from("2020-06-16"); const t = Temporal.Duration.from({ day: 1 }); const v = D.add(t) // 2020-06-17 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Duration https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- mkobit 6mo ago
  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/java/time/Duration.html 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/java/time/Period.html 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.extra/org/threeten/extra/Interval.html 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.
wesselbindt 6mo ago
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.
- throwaway_12629 6mo ago
  Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.
  - usefulcat 6mo ago
    // call foo() one day from now: sleep(86400); foo();
    - hdjrudni 6mo ago
      Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.
    - koakuma-chan 6mo ago
      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.
      - danbruc 6mo ago
        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.
        loloquwowndueo 6mo ago
        Only if you live in one of the brain dead countries that observe the dst anachronism.
patchnull 6mo ago
[dead]
QGQBGdeZREunxLe 6mo ago
Noticed that converting between certain calendars is not supported. Was that choice intentional? const today = Temporal.PlainDate.from("2569-03-11[u-ca=buddhist]"); today.toLocaleString("en", { calendar: "hebrew" }); > Uncaught RangeError: calendars "buddhist" and "hebrew" aren't compatible
- rmunn 6mo ago
  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).
- paradox460 6mo ago
  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"
- fabon 6mo ago
  I think this is intentional design. Anyway we can convert `Temporal.PlainDate` to other calendars explicitly (I believe explicitness is good here). today.withCalendar('hebrew').toLocaleString("en", { calendar: "hebrew" }); // "22 Adar 6329"
stevefan1999 6mo ago
I thought this Temporal is about the durable execution Temporal, well it is about time...
FireBeyond 6mo ago
> 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.
klysm 6mo ago
Bravo to the designers of this library. It’s well implemented and I’ve been using the poly fill for years now
sriramgonella 6mo ago
[flagged]
- tefkah 6mo ago
  ai;dr
Banou 6mo ago
Temporal is nice but I've tried using it and had terrible performances. Hope the implementations get better in the future.
eggsandbeer 6mo ago
[dead]
shevy-java 6mo ago
Good. Now someone has to fix JavaScript.
avandecreme 6mo ago
I didn't know about https://docs.rs/temporal_rs/latest/temporal_rs/ https://docs.rs/temporal_rs/latest/temporal_rs/ I wonder if it has a chance to replace chrono and jiff in the rust ecosystem.
- nekevss 6mo ago
  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 :)
corentin88 6mo ago
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.
- gjm11 6mo ago
  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?)
  - corentin88 6mo ago
pbowyer 6mo ago
If you were creating a new programming language in 2026, which DateTime/Temporal library would you copy and why?
nehalem 6mo ago
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 https://caniuse.com/temporal It will take years until this can be widely used as intended.
- halapro 6mo ago
  The spec hasn't even reached stage 4 yet. Chrome only added support 58 days ago. Safari already added support in their alphas.
  - nekevss 6mo ago
    The specification reached stage 4 just yesterday. That was the motive behind the blog post :)
  - nehalem 6mo ago
    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.
    - halapro 6mo ago
      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?
thinkindie 6mo ago
coming from PHP, it's incredible how many times I've been bitten by glitches with managing time with JS clientside.
ramon156 6mo ago
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!
parampathonmon2 6mo ago
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.
KolmogorovComp 6mo ago
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.
- fabon 6mo ago
  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.
matheus-rr 6mo ago
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.
gangnamdotori 6mo ago
Temporal API is fascinating. Time handling has always been painful in programming languages. Curious how widely this will get adopted in production systems.

790 points by robpalmer 6mo ago

Looking at the caniuse results... f*king Safari (and Opera)... https://caniuse.com/temporal https://caniuse.com/temporal

agos 6mo ago
I usually am not too harsh on Safari on implementation of new features but this is a bummer, and reflects poorly on them
beezlewax 6mo ago
And I have to support safari while dealing with all the problems that are mentioned in this article. Maybe there is a polyfill.
- jitl 6mo ago
  yes, there's a few different polyfills https://github.com/tc39/proposal-temporal/tree/main/#polyfills https://github.com/tc39/proposal-temporal/tree/main/#polyfil...
- tracker1 6mo ago
  Probably, but I'm guessing it's as big as moment.js ...
dmix 6mo ago
there's plenty of polyfills for every new JS idea on the roadmap
- tracker1 6mo ago
  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.
deleted 6mo ago
[deleted]
jitl 6mo ago
They've been working on support for a while (years), eg this 2022 commit. https://github.com/WebKit/WebKit/commit/e6717cdeb6a841f4b1f6b9d8d3b0dec947850abe https://github.com/WebKit/WebKit/commit/e6717cdeb6a841f4b1f6... perhaps don't be hard on them, Chrome released this to stable 2 months ago.

jon_kuperman 6mo ago

What a journey!

normie3000 6mo ago

No mention of JodaTime?

bnb 6mo ago

Can't wait for it to land in the server-side runtimes, really the last thing preventing me from adopting it wholesale.

apaprocki 6mo ago
Node 26! Only a matter of time... :)
CharlesW 6mo ago
FWIW, I've been using it server-side via the js-temporal polyfill for some time, no issues.
- bnb 6mo ago
  ooh I'd not seen that yet, will have to take a look.
WorldMaker 6mo ago
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.
ivankra 6mo ago
Try `node --harmony-temporal`

samwho 6mo ago

Thanks for linking to my silly little quiz in the article! :)

patchnull 6mo ago

[flagged]

virgil_disgr4ce 6mo ago
I think that actually may be the MOST appreciated design decision in Temporal ;) either way, I'm also a big fan
ndr 6mo ago
Immutability is underrated in general. It's a sore point every time I have to handle non-clojure code.
- recursive 6mo ago
  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.
  - LunaSea 6mo ago
    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.
    - recursive 6mo ago
      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.

virgil_disgr4ce 6mo ago

Pretty big fan of Temporal. Been using the polyfill for a while. Very nice to use a modern, extremely well thought-through API!

sharktheone 6mo ago

Very happy for it finally being there!

nekevss 6mo ago

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

plucas 6mo ago

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?

apaprocki 6mo ago
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.
- MBCook 6mo ago
  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.
mrkeen 6mo ago
Yep, JavaScript got the bad version from Java too! https://news.ycombinator.com/item?id=42816135 https://news.ycombinator.com/item?id=42816135
mexicocitinluez 6mo ago
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.

zvqcMMV6Zcr 6mo ago

> Safari (Partial Support in Technology Preview) Safari confirmed as IE Spiritual successor in 2020+.

cubefox 6mo ago
2026 A.D., still no support for native date pickers in mobile Safari.
- CharlesW 6mo ago
  Safari for iOS got native date pickers in 2012, and desktop Safari got them in 2021.
WorldMaker 6mo ago
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.
- nchmy 6mo ago
  > 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/ https://infrequently.org/2023/02/safari-16-4-is-an-admission... And an entire series: https://infrequently.org/series/browser-choice-must-matter/ https://infrequently.org/series/browser-choice-must-matter/

redbell 6mo ago

Oh, for a second, TeMPOraL (https://news.ycombinator.com/user?id=TeMPOraL https://news.ycombinator.com/user?id=TeMPOraL) came to my mind!

ChrisArchitect 6mo ago

A good article and discussion from January: Date is out, Temporal is in https://news.ycombinator.com/item?id=46589658 https://news.ycombinator.com/item?id=46589658

ChrisArchitect 6mo ago

Aside: Bloomberg JS blog? ok.

deepsun 6mo ago
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).
- ChrisArchitect 6mo ago
  oh, just meant it was a new tech blog from them.
  - jon_kuperman 6mo ago
    Yes! Brand new!
wiseowise 6mo ago
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 https://youtu.be/uqehwCWKVVw?is=wBijGwdD2k2jIOu7
robpalmer 6mo ago
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.

philipallstar 6mo ago

> 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?

nekevss 6mo ago
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.
WorldMaker 6mo ago
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.
- nekevss 6mo ago
  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.
apaprocki 6mo ago
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.
Anonyneko 6mo ago
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).

VanCoding 6mo ago

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.

qcoret 6mo ago
All Temporal objects are easily (de)serializable, though. `.toString` and `Temporal.from` work great.
- VanCoding 6mo ago
  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.
  - gowld 6mo ago
    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.
  - flyingmeteor 6mo ago
    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/Reference/Global_Objects/JSON/parse https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

hungryhobbit 6mo ago

From the article: const now = new Date(); The Temporal equivalent is: const now = Temporal.Now.zonedDateTimeISO(); 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? const now = DateTime();

sourcegrift 6mo ago
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.
- themafia 6mo ago
  I'm a programmer. I'm a human. Perhaps we should also allow for some "human theory" inside our understanding.
- Bratmon 6mo ago
  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!
evolve2k 6mo ago
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.

darepublic 6mo ago

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

lpa22 6mo ago
Same here, this is the way
NooneAtAll3 6mo ago
why UTC and not epoch then?
- SoftTalker 6mo ago
  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.
andrewl-hn 6mo ago
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.
- masfuerte 6mo ago
  > 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/Reference/Global_Objects/Temporal/PlainTime https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/PlainDateTime https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

newzino 6mo ago

[flagged]

kemayo 6mo ago

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

Griffinsauce 6mo ago
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.

aplomb1026 6mo ago

[flagged]

wpollock 6mo ago

> "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!

NooneAtAll3 6mo ago

so Temporal is copying cpp's std::chrono?

andrewl-hn 6mo ago
More like a copy of Java’s JSR310, which in turn took many years to get right.

SoftTalker 6mo ago

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.

xp84 6mo ago

They travelled through time (forward, at 1X) by nine years to do this for us. I appreciate it.

ilovesamaltman 6mo ago

[flagged]

johncomposed 6mo ago

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.

the__alchemist 6mo ago

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)

apaprocki 6mo ago
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.
jitl 6mo ago
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/ 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-build-another-datetime-library 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.

julius_eth_dev 6mo ago

[flagged]

cityofdelusion 6mo ago
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.
- SchemaLoad 6mo ago
  They do seem to be an LLM bot from comment history
- tshaddox 6mo ago
  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.
  - p1necone 6mo ago
    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).
- 6mo ago

patchnull 6mo ago

[flagged]

ventuss_ovo 6mo ago

interesting point about immutability

patchnull 6mo ago

[flagged]

sharifhsn 6mo ago
Your bot messed up and posted twice in the same thread.

alanning 6mo ago

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 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-many-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-meeting-across-time-zones https://tc39.es/proposal-temporal/docs/cookbook.html#book-a-...

kemitchell 6mo ago

> The first proposal I worked on was Promise.allSettled, which was fulfilling. Har har.

Animats 6mo ago

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 https://groups.google.com/g/comp.lang.python/c/Q2w4R89Nq1w

baliex 6mo ago
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.

Vinnl 6mo ago

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

sfink 6mo ago
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.
- apaprocki 6mo ago
  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!!
- sieabahlpark 6mo ago
  [dead]

bpiroman 6mo ago

I wish JavaScript held onto the name Mocha :)

tmpfile 6mo ago

I’d like to have interval types for example const D = new Temporal() const t = new Interval({minutes:5}) const v = D.add(t)

nikeee 6mo ago
It is called Duration.
- jitl 6mo ago
  a much less ambiguous name than Interval
plastic041 6mo ago
That's Duration! const D = Temporal.PlainDate.from("2020-06-16"); const t = Temporal.Duration.from({ day: 1 }); const v = D.add(t) // 2020-06-17 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Duration https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
mkobit 6mo ago
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/java/time/Duration.html 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/java/time/Period.html 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.extra/org/threeten/extra/Interval.html 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.

wesselbindt 6mo ago

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.

throwaway_12629 6mo ago
Technically, you're not likely to to have to fix a DST bug at 3AM any day but Sunday.
- usefulcat 6mo ago
  // call foo() one day from now: sleep(86400); foo();
  - hdjrudni 6mo ago
    Sorry, sleep returned a Promise and you didn't await it. You called foo() immediately.
  - koakuma-chan 6mo ago
    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.
    - danbruc 6mo ago
      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.
      - loloquwowndueo 6mo ago
        Only if you live in one of the brain dead countries that observe the dst anachronism.

patchnull 6mo ago

[dead]

QGQBGdeZREunxLe 6mo ago

Noticed that converting between certain calendars is not supported. Was that choice intentional? const today = Temporal.PlainDate.from("2569-03-11[u-ca=buddhist]"); today.toLocaleString("en", { calendar: "hebrew" }); > Uncaught RangeError: calendars "buddhist" and "hebrew" aren't compatible

rmunn 6mo ago
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).
paradox460 6mo ago
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"
fabon 6mo ago
I think this is intentional design. Anyway we can convert `Temporal.PlainDate` to other calendars explicitly (I believe explicitness is good here). today.withCalendar('hebrew').toLocaleString("en", { calendar: "hebrew" }); // "22 Adar 6329"

stevefan1999 6mo ago

I thought this Temporal is about the durable execution Temporal, well it is about time...

FireBeyond 6mo ago

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

klysm 6mo ago

Bravo to the designers of this library. It’s well implemented and I’ve been using the poly fill for years now

sriramgonella 6mo ago

[flagged]

tefkah 6mo ago
ai;dr

Banou 6mo ago

Temporal is nice but I've tried using it and had terrible performances. Hope the implementations get better in the future.

eggsandbeer 6mo ago

[dead]

shevy-java 6mo ago

Good. Now someone has to fix JavaScript.

avandecreme 6mo ago

I didn't know about https://docs.rs/temporal_rs/latest/temporal_rs/ https://docs.rs/temporal_rs/latest/temporal_rs/ I wonder if it has a chance to replace chrono and jiff in the rust ecosystem.

nekevss 6mo ago
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 :)

corentin88 6mo ago

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.

gjm11 6mo ago
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?)
- corentin88 6mo ago

pbowyer 6mo ago

If you were creating a new programming language in 2026, which DateTime/Temporal library would you copy and why?

nehalem 6mo ago

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 https://caniuse.com/temporal It will take years until this can be widely used as intended.

halapro 6mo ago
The spec hasn't even reached stage 4 yet. Chrome only added support 58 days ago. Safari already added support in their alphas.
- nekevss 6mo ago
  The specification reached stage 4 just yesterday. That was the motive behind the blog post :)
- nehalem 6mo ago
  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.
  - halapro 6mo ago
    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?

thinkindie 6mo ago

coming from PHP, it's incredible how many times I've been bitten by glitches with managing time with JS clientside.

ramon156 6mo ago

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!

parampathonmon2 6mo ago

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.

KolmogorovComp 6mo ago

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.

fabon 6mo ago
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.

matheus-rr 6mo ago

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.

gangnamdotori 6mo ago

Temporal API is fascinating. Time handling has always been painful in programming languages. Curious how widely this will get adopted in production systems.