22 ms·

JavaScript Temporal is coming

1405 points by SigmundurM 2y ago

pknerd 2y ago
Umm..I am not sure how the Islamic/Hijri calendar gonna work. Tomorrow is the first Shabaan in Pakistan but it is still 30th Rajab in Saudia. How will JS figure this difference out?
- justingrantjg 2y ago
  There are 5 different `islamic-*` calendars (and a `persian` calendar too) supported in JS today: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/supportedValuesOf#supported_calendar_types https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... There's no geographic adjustment but at least there is some choice for users about which Islamic calendar variation should be used. For example, "islamic-rgsa" in JS is the Hijri calendar, Saudi Arabia sighting. Temporal has built-in support for non-Gregorian calendars, including parsing, arithmetic, etc. so you can do things like this: Temporal.PlainDate.from("2025-01-30").withCalendar('islamic-rgsa').month // => 8 Temporal.PlainDate.from("2025-01-30[u-ca=islamic-rgsa]').month // => 8 function chineseNewYears() { const dt = Temporal.Now.plainDateISO().withCalendar('chinese'); const current = Temporal.PlainDate.from({year: dt.year, month: 1, day: 1, calendar: 'chinese'}) const next = current.add({years: 1}) return { current, next } } `The next Chinese New Year is ${chineseNewYears().next.withCalendar('gregory').toLocaleString('en-UK')}` // => 'The next Chinese New Year is 17/02/2026' More info about how calendars are used in Temporal is here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#calendars https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
TheAceOfHearts 2y ago
They should add an event to detect when someone changes timezones. That could be another entry in the "falsehoods that programmers believe about time": programmers believe that your timezone is fixed during usage. But in reality there are millions of people moving between timezones every day.
- nejsjsjsbsb 2y ago
  If you are on a plane or ISS you could even be timezoneless.
  - jofzar 2y ago
    Iss uses Coordinated Universal Time which is just GMT.
  - dtech 2y ago
    I.i.r.c. ISS uses UTC
    - noduerme 2y ago
      UTC for the win
  - esafak 2y ago
    Wouldn't you be in the time zone you are traveling over, the same as with other modes of transportation?
    - nejsjsjsbsb 2y ago
      You might but that isn't useful. Basically a web app will show you a time affected by your tailwind and weird geopolitics. (The weird politics are not so bad if you stay in the same time zone just changes 2 times a year)
- lblume 2y ago
  Where would you expect this event to be used? I don't think most web applications somewhat dependent on time should directly have to listen and respond to these events for the amount of people affected by it just doesn't justify the extra effort, I would assume. Libraries could benefit, of course.
  - TheAceOfHearts 2y ago
arnaudsm 2y ago
Relevant XKCD : https://xkcd.com/2867/ https://xkcd.com/2867/
- barrettondricka 2y ago
  Relevant Tom Scott video: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
- undebuggable 2y ago
  Well I failed one interview because to calculate number of days in between I suggested substracting Unix timestamps and dividing the difference by 86400.
  - blharr 2y ago
    Is there a problem with that or were the interviewers just being stubborn?
    - undebuggable 2y ago
      I understand the interviewer wanted to approach the problem as non decimal number of months in a year and variable number of days in a month. One day as the most granular entity. I didn't even wanted to argue over leap years and why the year 1900 wasn't one. It was consecutive meeting in a row and I was too tired for his shit.
srameshc 2y ago
If the time zone handling can be added like Golang time package, that would make it very convenient.
- noduerme 2y ago
  that'll work as soon as everyone in the world agrees to download the latest version of their favorite web browser each time Western Sahara is reclassified
  - Marazan 2y ago
    Deep cut. Also when the King of Morocco makes another snap decision about Ramadan timezones.
  - srameshc 2y ago
    We are anyways discussing the future :)
codeflo 2y ago
At first glance, this seems to be in the JodaTime/NodaTime/Js-Joda tradition of representing different "granularities" of date and time information with distinct types, e.g. with and without timezone information. I'm not sure if there's a formal relationship, since this seems to use different names. I personally like that approach, but I'm not sure how much sense that makes without static typing. (Maybe TypeScript is established enough that JavaScript APIs are now designed with TypeScript in mind?) From experience with js-joda, there's a definitely learning curve compared to moment's "one size fits all" type for all things date related. But I found that a lot of stupid mistakes of the kind "a person's age is wrong for an hour after midnight during daylight savings time" are prevented by default.
- baq 2y ago
  There’s a learning curve for developers who thought time is easy. The ones with battle scars will feel right at home.
nejsjsjsbsb 2y ago
Coming but only available in one browser or run time, and then with a feature flag.
- antihero 2y ago
  There's a polyfill in the meantime.
- creesch 2y ago
  That's generally how that works for new things like this. It is rare for a new thing like this to be adapted by everyone at the exact same time. Certainly within the context of browsers. There is a reason why websites like https://caniuse.com https://caniuse.com exist in the first place. If you pay attention you will also see that for APIs on MDN it will also have a browser compatibility list.
  - nejsjsjsbsb 2y ago
    Yes I am just saying how early this is. It is not a "watch out it may have some quirks on FF and break in Safari" early It's "Polyfill everywhere" early
  - nekevss 2y ago
    Mentioned elsewhere in this thread, but https://test262.fyi/# https://test262.fyi/# is great for keeping up to date with the current engine / interpreter support :)
- Cthulhu_ 2y ago
  Time and timezones are a big and complicated thing, I'm not surprised / appreciate they're taking their time with it. A library is temporary (ha) and is often superseded (e.g. momentjs -> luxon -> dayjs), but standard libraries are in it for the long time (Date has been around for 30 years and will be around for another 30 alongside Temporal).
noduerme 2y ago
Future generations will no doubt remember this announcement as a revolutionary leap into a brighter future. But I'm sure I'll still be using Moment.js ten years from now the way I'm still using JQuery 3.x now. Javascript is all we have for front end web apps now, impoverished as it is as a language. But excuse me if I don't get excited every time a proposal is rolled out to bring it close to the 21st century.
- Cthulhu_ 2y ago
  And that's fair, thanks to the compatibility guarantees, those libraries will continue to work long in the future. However, they're suboptimal; MomentJS is a relatively large and difficult to compress / tree-shake library, for example. Have you considered switching to Luxon? It should be a relatively small transition.
nobleach 2y ago
There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and Tuples going too! You can skip that silly Pipe-syntax war if you want!"
- noduerme 2y ago
  Records.. Wasn't Dictionary an ECMA5 proposal or was that just a novel touch in AS3? [edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly typed keys of any kind you specified. Errors thrown at compile time. God..I miss that language.]
  - jitl 2y ago
    We’ve had Map with those semantics since 2014, came out in Chrome a few months before Set. Record/Tuple objects are immutable primitives with structural equality, not object reference equality. So little relation to AS3 Dictionary/ES6 Map, besides being possible keys for Map/Set.
    - klabb3 2y ago
      > Record/Tuple objects are immutable primitives with structural equality TIL and also god that would be amazing, almost to the point of making JS/TS actually nice if done right (what’s next, pattern matching?). The number one footgun in JS imo is the combination of mutability and reference copying. Immutable or at least easy-to-copy plain old data is fantastic when it is well supported in the language.
      - for1nner 2y ago
phiresky 2y ago
Temporal is great. I've been using it for a while in production using a polyfill [1], and it solves all issues I've encountered with the old Date() API (which is a lot). It clearly takes inspiration from other high-quality time libraries such as chrono in Rust and Joda Time in Java and combines them into a nice API that's pretty comfortable to use. Yes, it is a bit more complex to handle since it separates time into naive time, instant and zoned time. But by experience, developers only confront complexity when they are forced to, and time _is_ complex. If you want to do the operation "add one day to this timestamp", you _must_ decide whether that timestamp is local to a specific timezone and which one. Otherwise you'll get a bug twice per year due to DST, or when the user switches time zones, or when you deploy on a server with a different timezone. It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris). [1]: https://www.npmjs.com/package/temporal-polyfill https://www.npmjs.com/package/temporal-polyfill
- tomtomtom777 2y ago
  > It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris). Could you elaborate on that? What is the issue?
  - SonOfLilit 2y ago
    Europe/Paris might change between now and the referenced time.
    - Piskvorrr 2y ago
      In other words, 2025-01-01T00:00+02:00 was NOT Europe/Paris (as it was CET at that time, GMT+1), 2024-08-01T00:00+02:00 could have been Europe/Paris (CEST, GMT+2), 2030-08-01T00:00+02:00 may be Europe/Paris (CEST, GMT+2), or perhaps not (CET, GMT+1). Or it may be a completely different TZ that incidentally shares the same offset at that time.
  - burntsushi 2y ago
andyjohnson0 2y ago
From TFA: > When JavaScript was created in 1995, the Date object was copied from Java's early, flawed java.util.Date implementation. Java replaced this implementation in 1997, but JavaScript is stuck with the same API for almost 30 years, despite known problems. I'm not a JavaScript or web developer, and I was surprised by the above. Can anyone comment on why the language was stuck with an inadequate api for so long? What are the forces at work here?
- baq 2y ago
  First rule of being a platform: Do Not Break Existing Code.
  - spiffyk 2y ago
    Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.
  - Cthulhu_ 2y ago
    That's fair, but they didn't need to - just make a new Date library and deprecate the old one.
- mrbluecoat 2y ago
  I've been a JavaScript developer since the nineties and I too have been puzzled about this very thing. Everyone has known Date has been broken for a very long time and a plethora of pollyfills and datetime libraries have sprung up to band-aid the situation but nothing ever got close to being resolved as major ECMAscript versions were released over the years. I guess if it takes 270 pages for MDN to explain it, it's a rocket science problem that's well over my head.
- rakatata 2y ago
  I think they thought they could get away with a hotfix like Intl.DateTimeFormat()
  - deleted 2y ago
SonOfLilit 2y ago
Can someone who's been following this explain why they're designing a new API instead of merging one of the successful open source APIs into the standard?
- jitl 2y ago
  There are plenty of very popular libraries that are low quality and/or have some major issues, popularity of a package is not necessarily indicative of a perfect design. When you put something into your language standard to be supported for the next 30 years you want to make sure it’s as correct for as many people as possible. “Oh this seems to work fine let’s merge it” is not a high enough bar. It’s inspired by JodaTime which got “merged” into Java, so you could say they are actually just merging an open source project, it’s just not one of the common JS ones.
- Cthulhu_ 2y ago
  Are those open source APIs standardized though? JS and browser standards are a different beast altogether than e.g. date library documentation. They need to write and specify exact behaviour, so that multiple implementations can be written by all relevant parties.
  - burntsushi 2y ago
    Indeed. For anyone interested in Temporal specifically, they can see the proposal here: https://tc39.es/proposal-temporal/ https://tc39.es/proposal-temporal/ Here's an example of the specification for computing the duration between two dates: https://tc39.es/proposal-temporal/#sec-temporal-calendardateuntil https://tc39.es/proposal-temporal/#sec-temporal-calendardate... (I picked one of the "simpler" ones. Have fun.)
- ko27 2y ago
  Temporal API is far more consequential than what was attempted before. Their proposal for serializing timezones is about to become the de facto standard extension to ISO 8601 (date/time).
  - 2y ago
nwroot 2y ago
Awesome. Can’t wait
SOLAR_FIELDS 2y ago
I was really confused for a minute, I thought this was referring to the Uber spinoff durable execution framework https://temporal.io/ https://temporal.io/
wim 2y ago
This is great. You need to write so much code to do conversion between arbitrary timezones reliably now. And even if you don't mind including yet another (large) dependency instead, even those almost all have problems around DST boundaries/ambiguous dates as you simply don't have access to the timezone rules in the browser right now.
jb1991 2y ago
This is the most extraordinary thing that I have personally seen in my career as a software developer, and I have worked in many different fields and different languages and on different platforms, but this is by a very wide margin the most exciting.
- deleted 2y ago
  [deleted]
- parasti 2y ago
  Why is it extraordinary? moment.js has been excellent for me, same for PHP's builtin DateTimeImmutable. What does this do that makes it extraordinary?
  - Cthulhu_ 2y ago
    It standardizes it across platforms and implementations; I mean you mention Moment.js, but it's been superseded by Luxon and DayJS ages ago; Moment is very large in terms of file size and doesn't support tree shaking, it creates mutable objects, same as Date, etc etc etc. But there's the problem. Use momentjs today and you're behind the times, but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years.
    - Capricorn2481 2y ago
      > but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years JS doesn't really have breaking changes. Until they do, MomentJS will always work. > It standardizes it across platforms and implementations Does it? I mean it prints the date and is a standard library, but I don't think it standardizes anything. Web doesn't really benefit from everyone using the same date library. It's all strings once it's sent over the wire.
  - trescenzi 2y ago
    One reason Temporal is a huge deal is because it differentiates between Date, Time, and DateTime. All of the libraries building on top of jsDate couldn't really do this effectively. I've been using Temporal in production now for about 2 years with a polyfill and while this distinction can be annoying at first, the ability to be so much more specific is very helpful.
deleted 2y ago
[deleted]
BostonFern 2y ago
It’s almost a shame, considering all the effort that went into Moment and Luxon, which will largely be superseded. Luxon especially is a joy to work with.
- lxgr 2y ago
  Another way of viewing this would be that these and other implementations have paved the way for standardization, which would possibly never have happened without them.
- SkyBelow 2y ago
  I spent a day fighting with date-fns trying to get some date calculations working and was to the point I was questioning if my entire approach was flawed because there was no reason I should be spending that much time figuring our some simple date calculations. Eventually I decided to try swapping to Luxon. 30 minutes later and it was all working. I'm still guessing I misunderstood something fundamental about date-fns, but for now I'm advocating for Luxon.
  - Macha 2y ago
    For the longest time date-fns approach to timezones was "Do you really need timezones? Aren't UTC offsets enough?" which was pretty fatal for a date time library, no matter how simple and light it makes your bundle. It looks like they did finally launch TZ support in September last year, and I haven't investigated it (and probably never will, given Temporal is coming a Temporal polyfill seems a better option)
    - agos 2y ago
      date-fn's gaslighting on timezones was so weird. I now see that they're planning duration support, but it's clear that its usefulness is fading
- icambron 2y ago
  Luxon author here. Obviously I (and many others!) put a lot into Luxon, but only because it seemed so useful. Now that it's hopefully becoming obsolete, I get to look at it fondly as a nice bridge to the future, and I appreciate all the love it's gotten. All things end.
angrygoat 2y ago
I used this (via polyfill) for my Typescript implementation of the calendar of the church, and it was fabulous. Using the old Javascript dates I felt like I was always tripping over something... this was actually nicer than Python's (already quite good) datetime support. https://github.com/grahame/church-calendar https://github.com/grahame/church-calendar
- cmcconomy 2y ago
  in python, 'pendulum' is the datetime swiss army knife. If you havent been using it, you should check it out
  - burntsushi 2y ago
    I'd suggest `whenever`, which has taken inspiration from Temporal: https://github.com/ariebovenberg/whenever https://github.com/ariebovenberg/whenever For Pendulum, I'd suggest folks take a gander at its issue list to see if the bugs reported are 1) real and 2) something you can live with. Well, when GitHub is back up anyway. Lol.
    - cmcconomy 2y ago
      Thanks for the headsup
    - angrygoat 2y ago
      thanks to you both, I'll check whenever and Pendulum out! :)
jjice 2y ago
Wow, this is great! We were using the proposal library at my job when I first joined, but switched to moment since Temporal seemed frozen. For what it's worth, moment is excellent too, but having good datetime support in the standard library is going to be fantastic.
- CharlieDigital 2y ago
  FYI, the Moment.js docs recommend not using Moment.js[0] > We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done. The author spells out a few pitfalls of Moment's design and why they're not addressing these as well as alternatives (Luxon, Day.js, date-fns, js-Joda) I've switched to Day.js instead[1] [0] https://momentjs.com/docs/#/-project-status/ https://momentjs.com/docs/#/-project-status/ [1] https://day.js.org/ https://day.js.org/
  - jjice 2y ago
    Oh thanks for the rec! I was aware that Moment was marking itself as legacy, but Day.js looks like a bonus here. Hopefully we can begin making the Temporal transition over the next few years though.
manbitesdog 2y ago
I get that the naming Temporal is used for avoiding conflicts with typical time objects like Moment, Datetime, etc. But isn't it a terrible name? At first glance I thought it was some kind of garbage collection control
- imdsm 2y ago
  I also think it's a terrible name. I'd even take DateV2 over this. I get they need backwards compatibility but Temporal sounds terrible. DateTime isn't by standard part of JS so why not use that? Until then const DateTime = Temporal
- shawabawa3 2y ago
  I thought it was Temporal the workflow engine in the browser
- reddalo 2y ago
  I agree, the naming is unfortunate. DateTime would have been way better.
- Eric_WVGG 2y ago
  I like it. got a Star Trek vibe.
- cosiiine 2y ago
  There's even the concept of "Temporal Dead Zone" in Javascript already which describes the period of time where variables aren't accessible.
- sensanaty 2y ago
  It sounds kinda cool and sci-fi-ey, but yeah I have a feeling I'm gonna struggle remembering the name of this new API lol
- Thorrez 2y ago
  temporal > 1. of or relating to time as opposed to eternity > 2. of or relating to grammatical tense or a distinction of time > 3. of or relating to time as distinguished from space https://www.merriam-webster.com/dictionary/temporal https://www.merriam-webster.com/dictionary/temporal Sounds like a good name to me.
keepamovin 2y ago
Handling dates is an archetypal engineering and logic puzzle to evaluate programmers.
liontwist 2y ago
The vast majority of websites should be calculating dates in a server and merely presenting them to clients. I have wondered why there isn’t a span style element which takes a UTC timestamp and presents it to the user in their preferred time zone. I even wonder if it could be done in private way so that JS cannot even access the value (made more difficult by layout and size). Similarly a form element for date times could simply return the UTC from the local choice. I am just wondering out loud and not an expert.
- yuchi 2y ago
  A lot of calculations may happen on the client. And the server may be written in JavaScript.
__bax 2y ago
Great Mozilla!
decatur 2y ago
With any new DateTime object in any language I usually look at its persistent fields to judge what the memory and access characteristics are. In case of Temporal it looks like that Chrome goes the JavaScript Date way as it only holds the timestamp: extern class JSTemporalInstant extends JSObject { nanoseconds: BigInt; } And then calendrical fields are computed on the fly. Is this correct?
nagstler 2y ago
Curious to see how Temporal works with JS on the client side! It’s an awesome tool for durable execution, I’ve been using it in my OSS projects, and it has been instrumental in building a leading Reverse ETL platform powered by Temporal. https://github.com/Multiwoven/multiwoven https://github.com/Multiwoven/multiwoven
- woogley 2y ago
  this is about a new datetime library in ecma standard, not the orchestration service temporal.io
temporallobe 2y ago
I’ve used date libraries from several languages and they’re all pretty awkward, but Ruby seems to have a very elegant solution thanks to the fact that primitives are also objects, so for example you can write things like 1.minute.ago or 1.day.from.now, which really helps in quick code comprehension.
- sensanaty 2y ago
  That would actually be ActiveSupport, which does many things and the pain of its absence is quickly felt in any non-Rails codebase :) https://rubygems.org/gems/activesupport https://rubygems.org/gems/activesupport
  - temporallobe 2y ago
    Yea, I forgot to mention that this was in a Rails context. In any case this is only possible because of Ruby’s primitives-as-objects design.
sensanaty 2y ago
Just want to chime in as someone who from time-to-time (heh) has to deal with datetime-related things and say, I hope for nuclear annihilation upon all clocks and other miscellaneous time-telling instruments, and most of all to whomever it is the world over that decides that, no, we're special and don't need to follow any kind of logic for our timezones (looking at you, China but also basically everyone else in the world). With that out of the way, very excited for Temporal and am very thankful to the people doing this hard work!
anshumankmr 2y ago
Salute to the folks who built momentjs... we used their stuff in prod and it worked like a charm
actinium226 2y ago
Finally!
qwertox 2y ago
Man, that took some time to find in the docs: Temporal.ZonedDateTime.prototype.withTimeZone() [0], which allows to convert from one timezone to another const meetingTime = Temporal.ZonedDateTime.from( "2021-08-01T12:00[America/New_York]", ); const meetingTimeInParis = meetingTime.withTimeZone("Europe/Paris"); console.log(meetingTimeInParis.toString()); // 2021-08-01T18:00:00+02:00[Europe/Paris] To me, timezone translations as well as durations are such an essential thing which libraries must handle, and it's nice to see that Temporal handles both. But it looks like Temporal.Duration doesn't offer a custom `format` function, for example `duration.format('H\hmm\m')` or something like that to format a duration into 1h03m. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime/withTimeZone https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- desmondwillow 2y ago
  The DurationFormatter proposal allows you control over which units you want formatted and at what brevity: eg. 1 yr, 3 hours, and 3m. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DurationFormat/format https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I partially implemented it in the icu4x library.
  - nekevss 2y ago
    Agreed this sounds like they are looking for Intl.DurationFormatter. Temporal.Duration.prototype.toLocaleString will end up using Intl.DurationFormatter though, so that will ultimately be what he wants (probably going to depend on that ICU4X implementation being complete though).
  - styfle 2y ago
    DurationFormat looks cool but it didn’t behave as I expected. https://github.com/tc39/proposal-intl-duration-format/issues/210 https://github.com/tc39/proposal-intl-duration-format/issues...
    - burntsushi 2y ago
samuell 2y ago
Thought this was about https://temporal.io/ https://temporal.io/ ...
ggregoire 2y ago
Anyone knows how the data about each timezone stays updated within Temporal? Does the TC39 update the data somewhere, then each browser copies that data internally and releases a new version of the browser? If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours? For example Mexico removed DST in 2022 [1]. When using third party libraries like pytz or moment-timezone, you just update the library on your side with the updated data for Mexico. Or bump the language if it's handled in the standard library. What about Temporal and my visitors' browser? [1] https://en.wikipedia.org/wiki/Time_in_Mexico https://en.wikipedia.org/wiki/Time_in_Mexico
- infogulch 2y ago
  Since it's built into the browser it's probably updated when the browser is updated. Browser vendors did a lot of work to update quickly, browsers are probably the most up-to-date software on your average person's computer.
  - baq 2y ago
    Please don't forget about us node users (and deno and bun I guess, too).
    - rough-sea 2y ago
      deno added this about a year ago https://docs.deno.com/api/web/~/Temporal https://docs.deno.com/api/web/~/Temporal https://deno.com/blog/v1.40#temporal-api https://deno.com/blog/v1.40#temporal-api
    - infogulch 2y ago
      If you're running years old js runtimes in a bigcorp that doesn't feel like updating for the next decade, I'll pray for you. (Because there's nothing else to do.)
      - 91bananas 2y ago
        Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20
infogulch 2y ago
Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1 https://bundlephobia.com/package/moment@2.30.1
- jb1991 2y ago
  The implications of Temporal are absolutely huge. This is a game-changer and I can't wait to see how everyone benefits, developers and users alike.
  - swyx 2y ago
    how are they huge?
    - WorldMaker 2y ago
      As mentioned a couple posts up, it would certainly help finally stop a lot of web applications (generally accidentally) bundling a bonus copy of the entire IANA TZ DB via Moment.js including it all by default "just in case". Cutting a lot of poor tree shaking out of the web by truly and finally "killing" Moment.js will be huge in download sizes if nothing else.
- kccqzy 2y ago
  I would start by arguing that not every website needs to deal with dates and times on the client side. And furthermore, if a website only needs to deal with dates but not times (surprisingly common) it can be done in a few KB of JavaScript—the Gregorian calendar is easy compared to the mess of ever-changing time zones and leap seconds.
  - syncsynchalt 2y ago
    I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience. I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.
Pikamander2 2y ago
> working with dates and times in JavaScript will be hugely simplified > To help you get up to speed, there are over 270 pages of Temporal docs on MDN Not that I'm complaining about extensive documentation, but seeing these two lines juxtaposed doesn't inspire much confidence.
- tcoff91 2y ago
  There is only so much you can do to simplify such a complex domain as time.
  - eviks 2y ago
    But there is a lot you can do to make your description reflect that reality
- ARandumGuy 2y ago
  MDN docs tend to be very thorough and well-written. It looks like most of these pages are for various utility functions, each of which has its own page.
- bsmth 2y ago
  Blog author here, I have to admit I enjoyed your comment. This is because it's mostly reference documentation, so each method of each class has it's own page, for example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#shared_class_interface https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- 91bananas 2y ago
  Dealing with dates and times and cache invalidation have been two of the hardest problems I've dealt with and the one uses the other.
- deleted 2y ago
  [deleted]
corentin88 2y ago
I have one question: why ˋTemporal`? That looks weird to me. Why now `Time`?
- tomwheeler 2y ago
  Right, a different name would avoid confusion with temporal.io.
  - beart 2y ago
    Is not `Time` a far more overloaded term than `Temporal`?
superkuh 2y ago
This is the first javascript change in a decade that actually seems like an improvement for web pages (and not just web applications). Nice.
huskywall 2y ago
Oh wow, I was complaining about working with dates in JavaScript around 2010 or so. It only took 15 years to sort this out.
- moffkalast 2y ago
  Well assuming this actually sorts it out, which remains to be seen.
  - ppseafield 2y ago
    Having used the API with a polyfill, it is a bit verbose and may seem a little obtuse at times. However, it allows you to explicitly differentiate between Date, Time, (Plain)DateTime, and ZonedDateTime. I have had to fix plenty of bugs because a datetime in the browser, datetime on the server, and UTC got mixed up at some point, and this API makes that a lot more difficult (and not likely to happen accidentally).
- Someone1234 2y ago
  Dates/Times/Calendars, and all the politics therein, is perhaps the second most complex thing computers are asked to do. The first being human languages (UNICODE, LTR Vs. RTL, CTL, Encoding, Sorting/Collation, Normalization, etc). Everyone agrees that Date in Javascript wasn't very good, but getting agreement over how to solve thousands of legitimately hard problems takes time. My viewpoint is that it is IMPRESSIVE it ONLY took them 15-years to get this far, and I congratulate everyone and all the hard work it took.
  - huskywall 2y ago
    Point taken, I realize it's complicated stuff. My gripe with it was more that other exotic features were being implemented while this was being neglected.
TheRealPomax 2y ago
Will this finally have a proper datetime formatter, too?
- lowmess 2y ago
  it'll work with Intl.DateTimeFormat
lostemptations5 2y ago
270 pages of documentation -- wonderful! /s
tzury 2y ago
The ECMAScript official docs. https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/ Not the most intuitive name though.
deleted 2y ago
[deleted]
ARandumGuy 2y ago
My work does a lot of stuff with time and scheduling, and let me tell you having timezone-unaware date/time objects distinct from specific points in time will be so damn useful. The old Date class made it really easy to accidentally screw that up. Third party libraries help, but something as important and fundamental as time really should have a good built-in implementation.
bilater 2y ago
Great video covering the API: https://youtu.be/oOK3UzLJ_Cs?si=1MJYtFBmcyJs4tLj https://youtu.be/oOK3UzLJ_Cs?si=1MJYtFBmcyJs4tLj
hinkley 2y ago
I was very confused why Mozilla was shilling for temporal.io
dakshgupta 2y ago
I might be mistaken but I think Hatchet.dev is a good Typescript alternative to Temporal
- darkbatman 2y ago
  Not the temporal you are thinking of. its Date replacement in JS.
brundolf 2y ago
Long-needed, though I think it'll take the ecosystem quite a while to catch up and standardize around it For one: a couple years ago my company migrated from moment to dayjs, which was a huge improvement and carried most of the benefits of Temporal. So even if it were available tomorrow, migration wouldn't be a super high priority for us Still a great thing!
wildpeaks 2y ago
I look forward to the day it's widely available. But red across the board at https://caniuse.com/temporal https://caniuse.com/temporal looks like it's still far away, and a 20Kb polyfill seems heavy compared to the 2Kb size of Day.js
- nekevss 2y ago
  https://test262.fyi/# https://test262.fyi/# will give you a bit better update on the progress on implementation in the various engines / interpreters :)
lofaszvanitt 2y ago
Holy fuck. This has some seriously fucked up syntax, function names and the like. Ugliest shit I've ever seen.
abtinf 2y ago
The name collision with Temporal, the popular durable execution service, is unfortunate.
zackmorris 2y ago
Carbon is a similar class in the PHP world that's inherited from DateTime. This gives a good description of how working with mutable timestamps can cause problems, because methods like $newInstance = $instance->addDay() modify the original instance and return it, rather than returning a copy that's a day later: https://carbon.nesbot.com/docs/ https://carbon.nesbot.com/docs/ So it's best to mostly use CarbonImmutable so that a new instance is always returned, which works better for higher-order programming style that's closer to pure functional programming. I do wish that Carbon was immutable by default, with CarbonMutable as a fallback when necessary, but it's too late for them to change it now. I could see a project using use..as statements and/or aliases in config/app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases like CRBN and CRBNMUT respectively, so that code works as intended without monkey patching or otherwise swapping the classnames and losing code portability.
- duskwuff 2y ago
  > I could see a project using use..as statements and/or aliases in config/app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases This wouldn't work the way you're hoping for. use statements are file-scoped; a use statement in config/app.php would only affect that configuration file, not the entire application.
  - zackmorris 2y ago
    Oh I was thinking of adding the custom CRBN or Carb or whatever as class aliases to the original CarbonImmutable class in config/app.php. I actually haven't used aliases yet though, so I'm going by the assumption that they "just work". I've had problems in other projects too where I wanted to disallow use of classes like Carbon after declaring a child class that overrides certain behaviors, so that the code is more future-proof for newly onboarded developers who don't know the pitfalls yet. In C/C++ I would just do: #define Carbon "Please don't use Carbon, use CRBN or CRBNMUT instead." So attempts to use Carbon would show up as compiler errors. But there are no #defines in PHP, so I haven't figured out a way to do that yet :-/ Maybe I could declare Carbon as a constant somewhere or something. But I don't think there's a way to undefine constants for times when the original word is needed, like with #undef.
indulona 2y ago
[dead]
orthoxerox 2y ago
How likely are we to get temporal literals? And in JSON?
- agos 2y ago
  your best bet is an RFC 9557 string
culi 2y ago
2024: Nested CSS 2025: Temporal Once we can style <option>'s HTML/CSS/ECMA will be complete. Thank you for everyone's hard work. Let's focus on interop and PWA apis!
- 8n4vidtmkvmk 2y ago
  I've needed these custom selects so many times... Including right now and I'm dreading building one from scratch again because all the libs I've found are lacking.
- fstephany 2y ago
  Oh wow, thank you. I didn't know nested CSS was a real thing nowadays.
ultim8k 2y ago
It’s been 84 years… Jokes aside, congrats to the team! This is huge news for JS.
aboutdamntime 2y ago
Why aren’t time zones enums and instead still text strings?
dang 2y ago
Related. Others? JavaScript Temporal Is Coming - https://news.ycombinator.com/item?id=42809834 https://news.ycombinator.com/item?id=42809834 - Jan 2025 (18 comments) Mozilla: Temporal (Limited Availability) - https://news.ycombinator.com/item?id=42776548 https://news.ycombinator.com/item?id=42776548 - Jan 2025 (1 comment) Is It Time for the JavaScript Temporal API? - https://news.ycombinator.com/item?id=29712118 https://news.ycombinator.com/item?id=29712118 - Dec 2021 (100 comments) Temporal: Getting started with JavaScript's new date time API - https://news.ycombinator.com/item?id=27661667 https://news.ycombinator.com/item?id=27661667 - June 2021 (194 comments) JavaScript Temporal - https://news.ycombinator.com/item?id=27395236 https://news.ycombinator.com/item?id=27395236 - June 2021 (1 comment) JavaScript Proposal Temporal for Dates is now stage 3 - https://news.ycombinator.com/item?id=26432346 https://news.ycombinator.com/item?id=26432346 - March 2021 (1 comment)
- Uninen 2y ago
  I appreciate how truly awesome the Web APIs are nowadays but I still feel sad that the first submission for this was almost 4 years ago in March 2021. Talk about slow turning ships!
mstade 2y ago
Providing comparison functions that work with existing APIs is solid design, should be required reading for any new types added really. Kudos to the designers! const durations = [ Temporal.Duration.from({ hours: 1 }), Temporal.Duration.from({ hours: 2 }), Temporal.Duration.from({ hours: 1, minutes: 30 }), Temporal.Duration.from({ hours: 1, minutes: 45 }), ]; durations.sort(Temporal.Duration.compare); console.log(durations.map((d) => d.toString())); // [ 'PT1H', 'PT1H30M', 'PT1H45M', 'PT2H' ]
stevage 2y ago
I've used Temporal a bit with a polyfill. It's a huge improvement. There's no "it's coming" really. With build processes and polyfills there's no reason to to use it already.
- deleted 2y ago
  [deleted]
- 8n4vidtmkvmk 2y ago
  The big bundle size is a reason.
  - stevage 2y ago
    Is it bigger than the equivalent Luxon or whatever? Or maybe I'm just fortunate to work in sectors where no one ever really cares about bundle size.
    - 8n4vidtmkvmk 2y ago
      Luxon is 23.4kB minified+gzipped, temporal-polyfill is actually 20.5kB. I'm surprised, I thought embedding all the timezone and calendar data and possibly translations would add a lot of bytes.
somishere 2y ago
Cannot wait. That said, somehow I don't think it will help us with a UK-based API provider we work with that provide us with ISO-encoded UTC time strings that are actually BST during northern hemisphere summer (or localised strings, e.g. +6 where the datetime component is actually UTC).
armanj 2y ago
wrote the whole `internationalization` instead of `i18n`. definitely not a developer.
nikeee 2y ago
I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be some version that relies on records and tuples, if these ever make it.
- modeless 2y ago
  I guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).
  - deleted 2y ago
    [deleted]
- brundolf 2y ago
  Is there any non-primitive JS type that has non-referential equality for ==?
  - tubthumper8 2y ago
    Yeah, that's one of the core problems, there's no overloading of equals in JS and no other cases of objects using non-reference equality. Adding that in itself would be a big deal (ex. see the Records and Tuples proposal which has been going on for years and may never complete)
  - 8n4vidtmkvmk 2y ago
    There's exactly one IIRC. document.all
- sureIy 2y ago
  Why not just use 'String()' or '2020-01-01'?
deleted 2y ago
[deleted]
ivanjermakov 2y ago
> Java replaced this implementation in 1997 I don't think it's safe to say, more direct comparison of JS's Temporal would be java.time[1], which was introduced in Java 1.8 in 2014. [1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/package-...
m3kw9 2y ago
JavaScript never supported support time zones is news to me
OptionOfT 2y ago
Very sad that .Now is not a function call. It shouldn't be a property. Evaluating .Now multiple times in a loop will yield different values, which is unexpected. C# did the same and it shouldn't have been: https://ericlippert.com/2014/05/19/when-should-i-write-a-property/ https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...
- yuchi 2y ago
  I think you got it wrong. Now is a namespace for functions that retrieve the actual values, such as Now.instant()
LAC-Tech 2y ago
It feels like temporal has been coming for 15 years.
throwaway2037 2y ago
Each time I see a programming language upgrade its base library to improve date/time handling, they all look eerily similar to the Java open source library JodaTime, which eventually became JSR-310 (essentially the "2.0" version of JodaTime in the Java base library). Does anyone else notice this? Except for leap seconds, I have never seen a real world business problem that I cannot solve with the current Java date/time APIs.
sublinear 2y ago
https://caniuse.com/?search=temporal https://caniuse.com/?search=temporal
dominicrose 2y ago
I've been waiting this "moment" for a long time...
himinlomax 2y ago
Is there something similar for Python? I only write the occasional script, and the default time functions are just bad.
me4502 2y ago
I'm honestly really excited for this to be more widely adopted to the point it can be used without polyfills. While the API is a little verbose for my liking, it's extremely capable. Being able to replace all the various date and time libraries with something browser-native is a massive win for bundle sizes, as even the most lightweight ones are going to start creeping up there once you're dealing with localisation on top of it.
tedk-42 2y ago
Sounds great! Just annoyed to use it I have to update all my unit test mocks for Date hahaha...
april1987 2y ago
> Implementations of the new JavaScript Temporal object are starting to be shipped in experimental releases of browsers. I can't get it working with Firefox developer edition or firefox nightly on Fedora Linux. What am I missing here? Can someone please guide me?
tempodox 2y ago
This looks great, and I'm getting jealous. Every language should have something like this in its stdlib.

1405 points by SigmundurM 2y ago

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

justingrantjg 2y ago
There are 5 different `islamic-*` calendars (and a `persian` calendar too) supported in JS today: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/supportedValuesOf#supported_calendar_types https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... There's no geographic adjustment but at least there is some choice for users about which Islamic calendar variation should be used. For example, "islamic-rgsa" in JS is the Hijri calendar, Saudi Arabia sighting. Temporal has built-in support for non-Gregorian calendars, including parsing, arithmetic, etc. so you can do things like this: Temporal.PlainDate.from("2025-01-30").withCalendar('islamic-rgsa').month // => 8 Temporal.PlainDate.from("2025-01-30[u-ca=islamic-rgsa]').month // => 8 function chineseNewYears() { const dt = Temporal.Now.plainDateISO().withCalendar('chinese'); const current = Temporal.PlainDate.from({year: dt.year, month: 1, day: 1, calendar: 'chinese'}) const next = current.add({years: 1}) return { current, next } } `The next Chinese New Year is ${chineseNewYears().next.withCalendar('gregory').toLocaleString('en-UK')}` // => 'The next Chinese New Year is 17/02/2026' More info about how calendars are used in Temporal is here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#calendars https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

TheAceOfHearts 2y ago

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

nejsjsjsbsb 2y ago
If you are on a plane or ISS you could even be timezoneless.
- jofzar 2y ago
  Iss uses Coordinated Universal Time which is just GMT.
- dtech 2y ago
  I.i.r.c. ISS uses UTC
  - noduerme 2y ago
    UTC for the win
- esafak 2y ago
  Wouldn't you be in the time zone you are traveling over, the same as with other modes of transportation?
  - nejsjsjsbsb 2y ago
    You might but that isn't useful. Basically a web app will show you a time affected by your tailwind and weird geopolitics. (The weird politics are not so bad if you stay in the same time zone just changes 2 times a year)
lblume 2y ago
Where would you expect this event to be used? I don't think most web applications somewhat dependent on time should directly have to listen and respond to these events for the amount of people affected by it just doesn't justify the extra effort, I would assume. Libraries could benefit, of course.
- TheAceOfHearts 2y ago

arnaudsm 2y ago

Relevant XKCD : https://xkcd.com/2867/ https://xkcd.com/2867/

barrettondricka 2y ago
Relevant Tom Scott video: https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY
undebuggable 2y ago
Well I failed one interview because to calculate number of days in between I suggested substracting Unix timestamps and dividing the difference by 86400.
- blharr 2y ago
  Is there a problem with that or were the interviewers just being stubborn?
  - undebuggable 2y ago
    I understand the interviewer wanted to approach the problem as non decimal number of months in a year and variable number of days in a month. One day as the most granular entity. I didn't even wanted to argue over leap years and why the year 1900 wasn't one. It was consecutive meeting in a row and I was too tired for his shit.

srameshc 2y ago

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

noduerme 2y ago
that'll work as soon as everyone in the world agrees to download the latest version of their favorite web browser each time Western Sahara is reclassified
- Marazan 2y ago
  Deep cut. Also when the King of Morocco makes another snap decision about Ramadan timezones.
- srameshc 2y ago
  We are anyways discussing the future :)

codeflo 2y ago

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

baq 2y ago
There’s a learning curve for developers who thought time is easy. The ones with battle scars will feel right at home.

nejsjsjsbsb 2y ago

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

antihero 2y ago
There's a polyfill in the meantime.
creesch 2y ago
That's generally how that works for new things like this. It is rare for a new thing like this to be adapted by everyone at the exact same time. Certainly within the context of browsers. There is a reason why websites like https://caniuse.com https://caniuse.com exist in the first place. If you pay attention you will also see that for APIs on MDN it will also have a browser compatibility list.
- nejsjsjsbsb 2y ago
  Yes I am just saying how early this is. It is not a "watch out it may have some quirks on FF and break in Safari" early It's "Polyfill everywhere" early
- nekevss 2y ago
  Mentioned elsewhere in this thread, but https://test262.fyi/# https://test262.fyi/# is great for keeping up to date with the current engine / interpreter support :)
Cthulhu_ 2y ago
Time and timezones are a big and complicated thing, I'm not surprised / appreciate they're taking their time with it. A library is temporary (ha) and is often superseded (e.g. momentjs -> luxon -> dayjs), but standard libraries are in it for the long time (Date has been around for 30 years and will be around for another 30 alongside Temporal).

noduerme 2y ago

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

Cthulhu_ 2y ago
And that's fair, thanks to the compatibility guarantees, those libraries will continue to work long in the future. However, they're suboptimal; MomentJS is a relatively large and difficult to compress / tree-shake library, for example. Have you considered switching to Luxon? It should be a relatively small transition.

nobleach 2y ago

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

noduerme 2y ago
Records.. Wasn't Dictionary an ECMA5 proposal or was that just a novel touch in AS3? [edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly typed keys of any kind you specified. Errors thrown at compile time. God..I miss that language.]
- jitl 2y ago
  We’ve had Map with those semantics since 2014, came out in Chrome a few months before Set. Record/Tuple objects are immutable primitives with structural equality, not object reference equality. So little relation to AS3 Dictionary/ES6 Map, besides being possible keys for Map/Set.
  - klabb3 2y ago
    > Record/Tuple objects are immutable primitives with structural equality TIL and also god that would be amazing, almost to the point of making JS/TS actually nice if done right (what’s next, pattern matching?). The number one footgun in JS imo is the combination of mutability and reference copying. Immutable or at least easy-to-copy plain old data is fantastic when it is well supported in the language.
    - for1nner 2y ago

phiresky 2y ago

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

tomtomtom777 2y ago
> It even solves the serialization issue of the difference between a "fixed-offset" timestamp (e.g. 2025-01-01T00:00+02:00) and one in a specific timezone (e.g. Europe/Paris). Could you elaborate on that? What is the issue?
- SonOfLilit 2y ago
  Europe/Paris might change between now and the referenced time.
  - Piskvorrr 2y ago
    In other words, 2025-01-01T00:00+02:00 was NOT Europe/Paris (as it was CET at that time, GMT+1), 2024-08-01T00:00+02:00 could have been Europe/Paris (CEST, GMT+2), 2030-08-01T00:00+02:00 may be Europe/Paris (CEST, GMT+2), or perhaps not (CET, GMT+1). Or it may be a completely different TZ that incidentally shares the same offset at that time.
- burntsushi 2y ago

andyjohnson0 2y ago

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

baq 2y ago
First rule of being a platform: Do Not Break Existing Code.
- spiffyk 2y ago
  Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.
- Cthulhu_ 2y ago
  That's fair, but they didn't need to - just make a new Date library and deprecate the old one.
mrbluecoat 2y ago
I've been a JavaScript developer since the nineties and I too have been puzzled about this very thing. Everyone has known Date has been broken for a very long time and a plethora of pollyfills and datetime libraries have sprung up to band-aid the situation but nothing ever got close to being resolved as major ECMAscript versions were released over the years. I guess if it takes 270 pages for MDN to explain it, it's a rocket science problem that's well over my head.
rakatata 2y ago
I think they thought they could get away with a hotfix like Intl.DateTimeFormat()
- deleted 2y ago

SonOfLilit 2y ago

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

jitl 2y ago
There are plenty of very popular libraries that are low quality and/or have some major issues, popularity of a package is not necessarily indicative of a perfect design. When you put something into your language standard to be supported for the next 30 years you want to make sure it’s as correct for as many people as possible. “Oh this seems to work fine let’s merge it” is not a high enough bar. It’s inspired by JodaTime which got “merged” into Java, so you could say they are actually just merging an open source project, it’s just not one of the common JS ones.
Cthulhu_ 2y ago
Are those open source APIs standardized though? JS and browser standards are a different beast altogether than e.g. date library documentation. They need to write and specify exact behaviour, so that multiple implementations can be written by all relevant parties.
- burntsushi 2y ago
  Indeed. For anyone interested in Temporal specifically, they can see the proposal here: https://tc39.es/proposal-temporal/ https://tc39.es/proposal-temporal/ Here's an example of the specification for computing the duration between two dates: https://tc39.es/proposal-temporal/#sec-temporal-calendardateuntil https://tc39.es/proposal-temporal/#sec-temporal-calendardate... (I picked one of the "simpler" ones. Have fun.)
ko27 2y ago
Temporal API is far more consequential than what was attempted before. Their proposal for serializing timezones is about to become the de facto standard extension to ISO 8601 (date/time).
- 2y ago

nwroot 2y ago

Awesome. Can’t wait

SOLAR_FIELDS 2y ago

I was really confused for a minute, I thought this was referring to the Uber spinoff durable execution framework https://temporal.io/ https://temporal.io/

wim 2y ago

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

jb1991 2y ago

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

deleted 2y ago
[deleted]
parasti 2y ago
Why is it extraordinary? moment.js has been excellent for me, same for PHP's builtin DateTimeImmutable. What does this do that makes it extraordinary?
- Cthulhu_ 2y ago
  It standardizes it across platforms and implementations; I mean you mention Moment.js, but it's been superseded by Luxon and DayJS ages ago; Moment is very large in terms of file size and doesn't support tree shaking, it creates mutable objects, same as Date, etc etc etc. But there's the problem. Use momentjs today and you're behind the times, but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years.
  - Capricorn2481 2y ago
    > but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years JS doesn't really have breaking changes. Until they do, MomentJS will always work. > It standardizes it across platforms and implementations Does it? I mean it prints the date and is a standard library, but I don't think it standardizes anything. Web doesn't really benefit from everyone using the same date library. It's all strings once it's sent over the wire.
- trescenzi 2y ago
  One reason Temporal is a huge deal is because it differentiates between Date, Time, and DateTime. All of the libraries building on top of jsDate couldn't really do this effectively. I've been using Temporal in production now for about 2 years with a polyfill and while this distinction can be annoying at first, the ability to be so much more specific is very helpful.

deleted 2y ago

[deleted]

BostonFern 2y ago

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

lxgr 2y ago
Another way of viewing this would be that these and other implementations have paved the way for standardization, which would possibly never have happened without them.
SkyBelow 2y ago
I spent a day fighting with date-fns trying to get some date calculations working and was to the point I was questioning if my entire approach was flawed because there was no reason I should be spending that much time figuring our some simple date calculations. Eventually I decided to try swapping to Luxon. 30 minutes later and it was all working. I'm still guessing I misunderstood something fundamental about date-fns, but for now I'm advocating for Luxon.
- Macha 2y ago
  For the longest time date-fns approach to timezones was "Do you really need timezones? Aren't UTC offsets enough?" which was pretty fatal for a date time library, no matter how simple and light it makes your bundle. It looks like they did finally launch TZ support in September last year, and I haven't investigated it (and probably never will, given Temporal is coming a Temporal polyfill seems a better option)
  - agos 2y ago
    date-fn's gaslighting on timezones was so weird. I now see that they're planning duration support, but it's clear that its usefulness is fading
icambron 2y ago
Luxon author here. Obviously I (and many others!) put a lot into Luxon, but only because it seemed so useful. Now that it's hopefully becoming obsolete, I get to look at it fondly as a nice bridge to the future, and I appreciate all the love it's gotten. All things end.

angrygoat 2y ago

I used this (via polyfill) for my Typescript implementation of the calendar of the church, and it was fabulous. Using the old Javascript dates I felt like I was always tripping over something... this was actually nicer than Python's (already quite good) datetime support. https://github.com/grahame/church-calendar https://github.com/grahame/church-calendar

cmcconomy 2y ago
in python, 'pendulum' is the datetime swiss army knife. If you havent been using it, you should check it out
- burntsushi 2y ago
  I'd suggest `whenever`, which has taken inspiration from Temporal: https://github.com/ariebovenberg/whenever https://github.com/ariebovenberg/whenever For Pendulum, I'd suggest folks take a gander at its issue list to see if the bugs reported are 1) real and 2) something you can live with. Well, when GitHub is back up anyway. Lol.
  - cmcconomy 2y ago
    Thanks for the headsup
  - angrygoat 2y ago
    thanks to you both, I'll check whenever and Pendulum out! :)

jjice 2y ago

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

CharlieDigital 2y ago
FYI, the Moment.js docs recommend not using Moment.js[0] > We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done. The author spells out a few pitfalls of Moment's design and why they're not addressing these as well as alternatives (Luxon, Day.js, date-fns, js-Joda) I've switched to Day.js instead[1] [0] https://momentjs.com/docs/#/-project-status/ https://momentjs.com/docs/#/-project-status/ [1] https://day.js.org/ https://day.js.org/
- jjice 2y ago
  Oh thanks for the rec! I was aware that Moment was marking itself as legacy, but Day.js looks like a bonus here. Hopefully we can begin making the Temporal transition over the next few years though.

manbitesdog 2y ago

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

imdsm 2y ago
I also think it's a terrible name. I'd even take DateV2 over this. I get they need backwards compatibility but Temporal sounds terrible. DateTime isn't by standard part of JS so why not use that? Until then const DateTime = Temporal
shawabawa3 2y ago
I thought it was Temporal the workflow engine in the browser
reddalo 2y ago
I agree, the naming is unfortunate. DateTime would have been way better.
Eric_WVGG 2y ago
I like it. got a Star Trek vibe.
cosiiine 2y ago
There's even the concept of "Temporal Dead Zone" in Javascript already which describes the period of time where variables aren't accessible.
sensanaty 2y ago
It sounds kinda cool and sci-fi-ey, but yeah I have a feeling I'm gonna struggle remembering the name of this new API lol
Thorrez 2y ago
temporal > 1. of or relating to time as opposed to eternity > 2. of or relating to grammatical tense or a distinction of time > 3. of or relating to time as distinguished from space https://www.merriam-webster.com/dictionary/temporal https://www.merriam-webster.com/dictionary/temporal Sounds like a good name to me.

keepamovin 2y ago

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

liontwist 2y ago

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

yuchi 2y ago
A lot of calculations may happen on the client. And the server may be written in JavaScript.

__bax 2y ago

Great Mozilla!

decatur 2y ago

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

nagstler 2y ago

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

woogley 2y ago
this is about a new datetime library in ecma standard, not the orchestration service temporal.io

temporallobe 2y ago

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

sensanaty 2y ago
That would actually be ActiveSupport, which does many things and the pain of its absence is quickly felt in any non-Rails codebase :) https://rubygems.org/gems/activesupport https://rubygems.org/gems/activesupport
- temporallobe 2y ago
  Yea, I forgot to mention that this was in a Rails context. In any case this is only possible because of Ruby’s primitives-as-objects design.

sensanaty 2y ago

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

anshumankmr 2y ago

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

actinium226 2y ago

Finally!

qwertox 2y ago

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

desmondwillow 2y ago
The DurationFormatter proposal allows you control over which units you want formatted and at what brevity: eg. 1 yr, 3 hours, and 3m. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DurationFormat/format https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I partially implemented it in the icu4x library.
- nekevss 2y ago
  Agreed this sounds like they are looking for Intl.DurationFormatter. Temporal.Duration.prototype.toLocaleString will end up using Intl.DurationFormatter though, so that will ultimately be what he wants (probably going to depend on that ICU4X implementation being complete though).
- styfle 2y ago
  DurationFormat looks cool but it didn’t behave as I expected. https://github.com/tc39/proposal-intl-duration-format/issues/210 https://github.com/tc39/proposal-intl-duration-format/issues...
  - burntsushi 2y ago

samuell 2y ago

Thought this was about https://temporal.io/ https://temporal.io/ ...

ggregoire 2y ago

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

infogulch 2y ago
Since it's built into the browser it's probably updated when the browser is updated. Browser vendors did a lot of work to update quickly, browsers are probably the most up-to-date software on your average person's computer.
- baq 2y ago
  Please don't forget about us node users (and deno and bun I guess, too).
  - rough-sea 2y ago
    deno added this about a year ago https://docs.deno.com/api/web/~/Temporal https://docs.deno.com/api/web/~/Temporal https://deno.com/blog/v1.40#temporal-api https://deno.com/blog/v1.40#temporal-api
  - infogulch 2y ago
    If you're running years old js runtimes in a bigcorp that doesn't feel like updating for the next decade, I'll pray for you. (Because there's nothing else to do.)
    - 91bananas 2y ago
      Smolcorp here, we just went from 12-20 across several large projects, it was gnarly. And now, 20 is already set to sunset soon. at some point it just feels like you should give up trying, but I'm hoping 20 to >20 isn't as bad as 12 -> 20

infogulch 2y ago

Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1 https://bundlephobia.com/package/moment@2.30.1

jb1991 2y ago
The implications of Temporal are absolutely huge. This is a game-changer and I can't wait to see how everyone benefits, developers and users alike.
- swyx 2y ago
  how are they huge?
  - WorldMaker 2y ago
    As mentioned a couple posts up, it would certainly help finally stop a lot of web applications (generally accidentally) bundling a bonus copy of the entire IANA TZ DB via Moment.js including it all by default "just in case". Cutting a lot of poor tree shaking out of the web by truly and finally "killing" Moment.js will be huge in download sizes if nothing else.
kccqzy 2y ago
I would start by arguing that not every website needs to deal with dates and times on the client side. And furthermore, if a website only needs to deal with dates but not times (surprisingly common) it can be done in a few KB of JavaScript—the Gregorian calendar is easy compared to the mess of ever-changing time zones and leap seconds.
- syncsynchalt 2y ago
  I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience. I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.

Pikamander2 2y ago

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

tcoff91 2y ago
There is only so much you can do to simplify such a complex domain as time.
- eviks 2y ago
  But there is a lot you can do to make your description reflect that reality
ARandumGuy 2y ago
MDN docs tend to be very thorough and well-written. It looks like most of these pages are for various utility functions, each of which has its own page.
bsmth 2y ago
Blog author here, I have to admit I enjoyed your comment. This is because it's mostly reference documentation, so each method of each class has it's own page, for example: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal#shared_class_interface https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
91bananas 2y ago
Dealing with dates and times and cache invalidation have been two of the hardest problems I've dealt with and the one uses the other.
deleted 2y ago
[deleted]

corentin88 2y ago

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

tomwheeler 2y ago
Right, a different name would avoid confusion with temporal.io.
- beart 2y ago
  Is not `Time` a far more overloaded term than `Temporal`?

superkuh 2y ago

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

huskywall 2y ago

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

moffkalast 2y ago
Well assuming this actually sorts it out, which remains to be seen.
- ppseafield 2y ago
  Having used the API with a polyfill, it is a bit verbose and may seem a little obtuse at times. However, it allows you to explicitly differentiate between Date, Time, (Plain)DateTime, and ZonedDateTime. I have had to fix plenty of bugs because a datetime in the browser, datetime on the server, and UTC got mixed up at some point, and this API makes that a lot more difficult (and not likely to happen accidentally).
Someone1234 2y ago
Dates/Times/Calendars, and all the politics therein, is perhaps the second most complex thing computers are asked to do. The first being human languages (UNICODE, LTR Vs. RTL, CTL, Encoding, Sorting/Collation, Normalization, etc). Everyone agrees that Date in Javascript wasn't very good, but getting agreement over how to solve thousands of legitimately hard problems takes time. My viewpoint is that it is IMPRESSIVE it ONLY took them 15-years to get this far, and I congratulate everyone and all the hard work it took.
- huskywall 2y ago
  Point taken, I realize it's complicated stuff. My gripe with it was more that other exotic features were being implemented while this was being neglected.

TheRealPomax 2y ago

Will this finally have a proper datetime formatter, too?

lowmess 2y ago
it'll work with Intl.DateTimeFormat

lostemptations5 2y ago

270 pages of documentation -- wonderful! /s

tzury 2y ago

The ECMAScript official docs. https://tc39.es/proposal-temporal/docs/ https://tc39.es/proposal-temporal/docs/ Not the most intuitive name though.

deleted 2y ago

[deleted]

ARandumGuy 2y ago

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

bilater 2y ago

Great video covering the API: https://youtu.be/oOK3UzLJ_Cs?si=1MJYtFBmcyJs4tLj https://youtu.be/oOK3UzLJ_Cs?si=1MJYtFBmcyJs4tLj

hinkley 2y ago

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

dakshgupta 2y ago

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

darkbatman 2y ago
Not the temporal you are thinking of. its Date replacement in JS.

brundolf 2y ago

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

wildpeaks 2y ago

I look forward to the day it's widely available. But red across the board at https://caniuse.com/temporal https://caniuse.com/temporal looks like it's still far away, and a 20Kb polyfill seems heavy compared to the 2Kb size of Day.js

nekevss 2y ago
https://test262.fyi/# https://test262.fyi/# will give you a bit better update on the progress on implementation in the various engines / interpreters :)

lofaszvanitt 2y ago

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

abtinf 2y ago

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

zackmorris 2y ago

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

duskwuff 2y ago
> I could see a project using use..as statements and/or aliases in config/app.php (edit: in Laravel) to import CarbonImmutable and Carbon as aliases This wouldn't work the way you're hoping for. use statements are file-scoped; a use statement in config/app.php would only affect that configuration file, not the entire application.
- zackmorris 2y ago
  Oh I was thinking of adding the custom CRBN or Carb or whatever as class aliases to the original CarbonImmutable class in config/app.php. I actually haven't used aliases yet though, so I'm going by the assumption that they "just work". I've had problems in other projects too where I wanted to disallow use of classes like Carbon after declaring a child class that overrides certain behaviors, so that the code is more future-proof for newly onboarded developers who don't know the pitfalls yet. In C/C++ I would just do: #define Carbon "Please don't use Carbon, use CRBN or CRBNMUT instead." So attempts to use Carbon would show up as compiler errors. But there are no #defines in PHP, so I haven't figured out a way to do that yet :-/ Maybe I could declare Carbon as a constant somewhere or something. But I don't think there's a way to undefine constants for times when the original word is needed, like with #undef.

indulona 2y ago

[dead]

orthoxerox 2y ago

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

agos 2y ago
your best bet is an RFC 9557 string

culi 2y ago

2024: Nested CSS 2025: Temporal Once we can style <option>'s HTML/CSS/ECMA will be complete. Thank you for everyone's hard work. Let's focus on interop and PWA apis!

8n4vidtmkvmk 2y ago
I've needed these custom selects so many times... Including right now and I'm dreading building one from scratch again because all the libs I've found are lacking.
fstephany 2y ago
Oh wow, thank you. I didn't know nested CSS was a real thing nowadays.

ultim8k 2y ago

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

aboutdamntime 2y ago

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

dang 2y ago

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

Uninen 2y ago
I appreciate how truly awesome the Web APIs are nowadays but I still feel sad that the first submission for this was almost 4 years ago in March 2021. Talk about slow turning ships!

mstade 2y ago

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

stevage 2y ago

I've used Temporal a bit with a polyfill. It's a huge improvement. There's no "it's coming" really. With build processes and polyfills there's no reason to to use it already.

deleted 2y ago
[deleted]
8n4vidtmkvmk 2y ago
The big bundle size is a reason.
- stevage 2y ago
  Is it bigger than the equivalent Luxon or whatever? Or maybe I'm just fortunate to work in sectors where no one ever really cares about bundle size.
  - 8n4vidtmkvmk 2y ago
    Luxon is 23.4kB minified+gzipped, temporal-polyfill is actually 20.5kB. I'm surprised, I thought embedding all the timezone and calendar data and possibly translations would add a lot of bytes.

somishere 2y ago

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

armanj 2y ago

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

nikeee 2y ago

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

modeless 2y ago
I guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).
- deleted 2y ago
  [deleted]
brundolf 2y ago
Is there any non-primitive JS type that has non-referential equality for ==?
- tubthumper8 2y ago
  Yeah, that's one of the core problems, there's no overloading of equals in JS and no other cases of objects using non-reference equality. Adding that in itself would be a big deal (ex. see the Records and Tuples proposal which has been going on for years and may never complete)
- 8n4vidtmkvmk 2y ago
  There's exactly one IIRC. document.all
sureIy 2y ago
Why not just use 'String()' or '2020-01-01'?

deleted 2y ago

[deleted]

ivanjermakov 2y ago

> Java replaced this implementation in 1997 I don't think it's safe to say, more direct comparison of JS's Temporal would be java.time[1], which was introduced in Java 1.8 in 2014. [1]: https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html https://docs.oracle.com/javase/8/docs/api/java/time/package-...

m3kw9 2y ago

JavaScript never supported support time zones is news to me

OptionOfT 2y ago

Very sad that .Now is not a function call. It shouldn't be a property. Evaluating .Now multiple times in a loop will yield different values, which is unexpected. C# did the same and it shouldn't have been: https://ericlippert.com/2014/05/19/when-should-i-write-a-property/ https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...

yuchi 2y ago
I think you got it wrong. Now is a namespace for functions that retrieve the actual values, such as Now.instant()

LAC-Tech 2y ago

It feels like temporal has been coming for 15 years.

throwaway2037 2y ago

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

sublinear 2y ago

https://caniuse.com/?search=temporal https://caniuse.com/?search=temporal

dominicrose 2y ago

I've been waiting this "moment" for a long time...

himinlomax 2y ago

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

me4502 2y ago

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

tedk-42 2y ago

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

april1987 2y ago

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

tempodox 2y ago

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