Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript Temporal is coming

developer.mozilla.org

Post reply on HN
Print view View original

161–170 of 416 posts

Re: JavaScript Temporal is coming

#161

Post by infogulch »

ggregoire wrote: post #153

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 m…

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.

Re: JavaScript Temporal is coming

#162

Post by burntsushi »

ggregoire wrote: post #153

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 m…

On Unix systems (including Linux distros, macOS and Android), there is a system copy of the IANA Time Zone Database. I actually don't know if browsers use that or if they ship their own copy. But Temporal definitely uses the IANA tzdb.

> If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours?

Yeah I think this is generally correct. But I don't think that's a departure from current norms? I think this is also just true in general. If the user doesn't update to their system to account for new time zone transition rules then that's just kinda how the cookie crumbles.

The alternative is that every application ships their own tzdb. And to be clear, some do that and sometimes it is warranted. But in general this would be wasteful and likely lead overall to inconsistency between applications and likely a slower cadence of updates. (Because now every application has to be updated and shipped out again.)

Re: JavaScript Temporal is coming

#163

Post by esafak »

nejsjsjsbsb wrote: post #8
TheAceOfHearts wrote: post #2

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.

If you are on a plane or ISS you could even be timezoneless.

Wouldn't you be in the time zone you are traveling over, the same as with other modes of transportation?

Re: JavaScript Temporal is coming

#164

Post by andrewmcwatters »

z3t4 wrote: post #37
nobleach wrote: post #13

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…

It's not just the major browser makers. I was working on a JavaScript inference engine around when ES6 started to roll out, I had decent ES5 support but when all the syntatic updates came I had to give up. They basically killed the JavaScript ecosystem with all the updates. We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

Come now, this is silly. There are plenty of us that are explicitly avoiding build phases because, for us, what needs to be built adds very little benefit.

Working with assembly is comparatively expert work that few professionals are good at. JavaScript can be written by kids.

Re: JavaScript Temporal is coming

#165

Post by baq »

infogulch wrote: post #161
ggregoire wrote: post #153

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 m…

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.

Please don't forget about us node users (and deno and bun I guess, too).

Re: JavaScript Temporal is coming

#166

Post by Pikamander2 »

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

Re: JavaScript Temporal is coming

#168

Post by burntsushi »

btown wrote: post #159
burntsushi wrote: post #125

Earlier quoted context omitted.

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,…

Yeah the PostgreSQL situation is just utterly appalling. The fact that there is a type called "timestamp with time zone," that specifically calls out the fact that it has a time zone, but actually doesn't have a time zone is absolutely crazytown.

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

Yeah! It's great that Temporal rejects by default, but does let you override that and choose whether to respect the instant or respect to the civil time. And it lets you do that with a high level configuration knob. You don't have to code up the logic yourself.

Re: JavaScript Temporal is coming

#169

Post by infogulch »

baq wrote: post #165
infogulch wrote: post #161

Earlier quoted context omitted.

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.

Please don't forget about us node users (and deno and bun I guess, too).

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

Re: JavaScript Temporal is coming

#170

Post by haburka »

ggregoire wrote: post #153

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 m…

Reading the proposal page “ Time Zones and Resolving Ambiguity”[1], it only mentions that it uses the IANA time zone database[2] not when it updates it. However I imagine the users computer has access to this database as well and probably handles it being updated. I’m not sure about this. It’s also entirely possible for the browser to download this database and maintain it too, separately from updates. I’m sure it depends on the implementation.

[1] https://tc39.es/proposal-temporal/docs/timezone.html

[2] https://en.wikipedia.org/wiki/Tz_database

Post reply on HN