Thought this was about https://temporal.io/ ...
JavaScript Temporal is coming
151–160 of 416 posts
Re: JavaScript Temporal is coming
#152Earlier quoted context omitted.
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.
> 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.
> what’s next, pattern matching?
Oh boy do I have news for you... https://tc39.es/proposal-pattern-matching/
:P
Re: JavaScript Temporal is coming
#153Anyone 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?
Re: JavaScript Temporal is coming
#154Earlier quoted context omitted.
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
You've just introduced timezones
It always cracks me up when people think they are proposing a simpler system by ignoring complexity. Is akin to people saying, "why don't we just change the start/end time of schools/businesses instead of changing the clock back?" As if getting companies to agree to when to make a change, and updating all of their documents/signage/etc. would somehow be easier than allowing them to continue to say "open at 8."
For this one, It really amuses me on how they think they would accomplish keeping someone's phone to alarm at the equivalent of 7am when they fly across a nation.
Granted, I still hold the silly view that we should probably change daylight savings time to be a 10 minute change of the clock every month. Up for six months, down for 6 months. Would effectively be trying to tie it to actual solar time, which is what we seem to care about. And would be trivial with modern devices. (Though, no, I don't hold that this will happen.)
Re: JavaScript Temporal is coming
#155Man, 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 transl…
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/Refe...
I partially implemented it in the icu4x library.
Re: JavaScript Temporal is coming
#156From 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?…
Going back even further in time, Java.util.Date was was heavily inspired by a C library.
That’s the origin of getMonth() in Java (and therefore in JS) returning a value from 0-11 and not 1-12 as many coders initially expect.
What was the origin for this peculiarity in C? That I don’t know, but I’m curious to find out if anyone knows.
Re: JavaScript Temporal is coming
#157Does 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
Re: JavaScript Temporal is coming
#158Earlier quoted context omitted.
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…
It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets. That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. All of this is kept t…
> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened.
It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city.
You obviously can't put every hamlet, town and village into tzdb, for a lot of reasons. So, if you're trying to represent a time in a place that isn't in tzdb, you have to pick the nearest location that is in tzdb. And it's quite possible that between when you enter your time and when that time comes to pass, the location you were specifying for changes it's rules in a way that's different from the original place you chose.
If you bisect a city, you could create two new names, so that if you encountered the old name you'd know that something needed to be reconciled. But if you chose the nearest place and then your rules changed, you'd have no way to know automatically that it needed to be revisited.
For example, parts of Chile decided not to do DST any more. To support this, a new timezone, America/Punta_Arenas, was added to tzdb. Before this, if you were in Punta Arenas, you would just put all your times as America/Santiago. And now you have no way of knowing if those times are really supposed to be Santiago or if they were Punta Arenas and Santiago was just the best you could do at the time.
Location-based tz's are the best we can do right now but even still they have intractable problems when things change.
Re: JavaScript Temporal is coming
#159Earlier quoted context omitted.
While this is true, most often if you want to do "now plus a month" you'll mean "at the same time on the local clock", and disregarding timezone changes, while most often if you want to do "now plus four hours" you'd actually mean four real hours, and you want to calculate in the DST changes to make sure you have four actual hours in your duration
That's how Temporal works: >> zdt = Temporal.ZonedDateTime.from("2024-03-09T17:00-05[US/Eastern]") >> zdt.add("P1d").toString() "2024-03-10T17:00:00-04:00[US/Eastern]" >> zdt.add("PT24h").toString() "2024-03-10T18:00:00-04:00[US/Eastern]" If you don't have the time zone and instead just an offset, then Temporal can't do this: >> zdt = Temporal.ZonedDateTime.from("2024-03-09T17:00-05[-05]") >> zdt.add("P1d").toString(…
https://datatracker.ietf.org/doc/rfc9557/ for folks' reference about the new [] suffix syntax.
It's a really well thought out RFC: the offset, the civil time zone name, and a flag for whether that civil time zone is critical information can all be stored, and an inconsistency marked critical MUST be acted upon by the application explicitly, either by rejecting or requesting user interaction.
This may seem redundant, but it's really important to answer "what happens if I have a future timestamp stored, and the USA suddenly rejects daylight savings time. Do I honor the absolute point in time, or do I honor the notion of 5pm?"
Unfortunately, there's going to be a lot of chaos if this happens. Systems like Postgres only store the absolute point in time, normalized to UTC, despite what the name "timestamp with time zone" might imply; an application team or DBA making a decision about this might need to look at other domain-specific metadata e.g. the physical location of the associated asset to determine whether to add or remove an hour. I shudder to think about what this might imply for e.g. HIPAA protected medical systems; the impact of the ensuing bugs might be measured in lives.
Re: JavaScript Temporal is coming
#160Does 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
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.