81–90 of 416 posts
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?
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.
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?
Earlier quoted context omitted.
And lived on a flat planet.
That’s not a valid argument. There is no reason why people in Japan couldn’t start their workday at 03:00, or people in France at 22:00
Time zones aren't just so everyone on the planet can start work at 09:00 local time. They're also for snapping everyone in a region to a shared time, even if it's a little off from their solar time.
Check out the history of railway time for the birth of time zones: https://en.wikipedia.org/wiki/Railway_time
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.
Earlier quoted context omitted.
> 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?
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…
https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan...
Earlier quoted context omitted.
And lived on a flat planet.
That’s not a valid argument. There is no reason why people in Japan couldn’t start their workday at 03:00, or people in France at 22:00
Can someone who's been following this explain why they're designing a new API instead of merging one of the successful open source APIs into the standard?
Are those open source APIs standardized though? JS and browser standards are a different beast altogether than e.g. date library documentation. They need to write and specify exact behaviour, so that multiple implementations can be written by all relevant parties.
Here's an example of the specification for computing the duration between two dates: https://tc39.es/proposal-temporal/#sec-temporal-calendardate...
(I picked one of the "simpler" ones. Have fun.)
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