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

231–240 of 416 posts

Re: JavaScript Temporal is coming

#231

Post by nekevss »

desmondwillow wrote: post #155
qwertox wrote: post #146

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

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

Re: JavaScript Temporal is coming

#233

Post by mikepurvis »

WorldMaker wrote: post #223
Cthulhu_ wrote: post #69

Earlier quoted context omitted.

I wonder what happens when a timezone ceases to exist, e.g. what if Paris is renamed to New New York after the British take revenge and take over France.

https://www.icann.org/en/blogs/details/how-time-zones-are-co... Hopefully the British would be kind enough to email the TZ DB group at the IANA (tz@iana.org) a couple years in advance of the legislation to change the name so that the group can get started on collecting the DST rules for Europe/NewNewYork. Some people and devices will probably stick to Europe/Paris out of habit and/or resistance to the change, so the…

As a Canadian, I would love for my timezone to be Americas/Toronto or Americas/Canada/Toronto rather than America/Toronto, but that's pretty far down my register of first world problems.

Re: JavaScript Temporal is coming

#234

Post by beart »

91bananas wrote: post #214
infogulch wrote: post #169

Earlier quoted context omitted.

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

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

I know it doesn't always work out, but it definitely helps to keep current, rather than performing a massive update every X years. Most of the time the changes are minimal, but they add up over several major revisions.

Of course, every now and then something like eslint will completely break every project in existence by changing the configuration format, then you have to wait for all of the plugins to be updated (if ever), then hope all your linting rules are still valid... yeah I'm still bitter about that one.

Re: JavaScript Temporal is coming

#235

Post by WorldMaker »

DanielHB wrote: post #46
andyjohnson0 wrote: post #25

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

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…

> during the IE5/IE6 era

During that era was a peak of browser innovation. IE5 and IE6 contributed a lot of things to web standards. They contributed a bunch of things that web standards eventually rejected too, but that was the risk of innovation at the time.

It was the period between IE6's last feature update and IE7's first release where Microsoft declared the browser wars "finished" and disbanded the IE team entirely that was the Darkest Age. So about 2001-2006 were the darkest few years.

It certainly had repercussions until around 2010, but the worst "sabotages" were done and gone by then. "Legacy" problems.

Re: JavaScript Temporal is coming

#236

Post by nekevss »

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…

It's going to depend on the implementation and the system. The implementation will probably end up needing to define a time zone provider, which will ultimately be provided by host/system hooks provided to Temporal from the engine implementation.

Re: JavaScript Temporal is coming

#237

Post by WorldMaker »

swyx wrote: post #179
jb1991 wrote: post #160

Earlier quoted context omitted.

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.

how are they huge?

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.

Re: JavaScript Temporal is coming

#238

Post by nekevss »

wildpeaks wrote: post #212

I look forward to the day it's widely available. But red across the board at 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

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

Re: JavaScript Temporal is coming

#239

Post by [deleted] »

scarface_74 wrote: post #55
lblume wrote: post #12

Earlier quoted context omitted.

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.

First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. Say my normal work day is from 8-5 and I work in the Eastern time zone. I set my Slack DND to outside those hours. I hop on a plane and go somewhere on the west coast. The perfect case, Slack would notify me of the change and let me decide whether I wanted to adjust the DND to local time or keep it. There are two possible scenarios f…

[deleted]

Re: JavaScript Temporal is coming

#240

Post by nekevss »

DanielHB wrote: post #42
phiresky wrote: post #23

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…

> time _is_ complex If only humans could read int64 epoch values

if only it was as simply a reading int64 epoch values :')
Post reply on HN