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.
JavaScript Temporal is coming
91–100 of 416 posts
Re: JavaScript Temporal is coming
#92I 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
Re: JavaScript Temporal is coming
#93Handling dates is an archetypal engineering and logic puzzle to evaluate programmers.
Re: JavaScript Temporal is coming
#94The 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.
Re: JavaScript Temporal is coming
#95Earlier quoted context omitted.
The issue is that if you have a timestamp (e.g., `2025-06-20T17:00:00+02:00`) and a time zone (e.g., `Europe/Paris`) and you go to serialize it, are you explicitly including the time zone in that serialization? And when you deserialize it, are you checking that the offset is still valid for that time zone at that time? Temporal fixes this by using RFC 9557[1], which includes the time zone in the serialized representa…
I get that it’s more correct, but it assumes that Europe/Paris is a constant representation of how to apply the timezone-specific stuff but that’s incorrect. For example, ‘2025-06-20T17:00:00+02[Europe/Dublin]’ is a very different time if it’s created today vs if it were created in 1760 [1]. That’s a very extreme example, but timezone rules change and dates created from before the change was announced would be interp…
Can you provide a concrete example? Ideally using Temporal to show where it's going wrong. Like, if you created `2025-06-20T17:00:00+02[Europe/Dublin]` (the instant) in 1760, then its civil representation would be different, to account for the rules in place at the time. And then if you went to deserialize it today, Temporal would reject it. You'd get an error, because the rules in place when the string was serialized don't match the rules in place today for that instant.
To be clear, I might be misunderstanding what you're saying. So that's why I'm asking for a concrete example. That will cut through everything. And if you didn't, I would strongly suggest you take a look at https://tc39.es/proposal-temporal/docs/zoneddatetime.html and search for "conflict". I think that will help explain things.
> I get that it’s more correct
We can chase perfection, but perfection isn't the goal. All models are wrong, but some are useful. In other words, the question isn't whether Temporal's model of interaction with time is wrong (it is!), it's how wrong it is and what its impact is that matters.
Re: JavaScript Temporal is coming
#96They 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.
How would the runtime know that though? If you're in a plane with no internet, or if you're privacy conscious and you have location services turned off, there's no way for the JS engine to know you're in a different timezone. I mean your argument has some merit but I'd argue that "you get the new timezone if you create a new date after your system updates its local timezone" is good enough. Furthermore, most applicat…
> someone reading a log will want server time or UTC
I personally prefer local times when reading logs, but I'll absolutely take UTC over a wrong local time.
Re: JavaScript Temporal is coming
#97From 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?…
Well browser standards were pretty much gimped by microsoft during the IE5/IE6 era, so from 1998 until around 2010 there was no progress on standards and Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share. From 2010 until about 2020 I would say the standard committee took hold and they have been quite busy with other things. Since JS is a langua…
> Microsoft was actively trying to prevent web applications from becoming a thing in order to not damage Windows market share.
Boy, it's a different company doing this now, but this is definitely still something that is happening, especially in mobile.
Re: JavaScript Temporal is coming
#98Temporal 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…
why does the polyfill have dependencies? And it's 200KB alone compared to 60KB of moment.
Re: JavaScript Temporal is coming
#99I 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
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
Re: JavaScript Temporal is coming
#100Great Mozilla!