Live data from Hacker News

JavaScript Temporal is coming

developer.mozilla.org

101–110 of 416 posts

Re: JavaScript Temporal is coming

#101
post #41

Earlier quoted context omitted.

Suggestion, design your app to not be time zone dependant if at all possible. For example, store dates in UTC and render instantaneously in current time zone.

That only works for past events, not future ones. Converting to UTC is lossy so rendering timestamps correctly in the future becomes problematic with DST/TZ rule changes.

Really depends on what you want to do. If it's something like "set the date at which new system behavior x becomes effective", UTC is perfectly fine; for scheduling a meeting, not so much.

Re: JavaScript Temporal is coming

#102

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…

The one I want is pattern matching ( https://tc39.es/proposal-pattern-matching/ ), which is still at stage 1 so many years away, sadly.

Pattern matching (and expression based assignment, of which idk if there’s a proposal for or not) are two things that would really drive a ton of value.

Re: JavaScript Temporal is coming

#103

It’s almost a shame, considering all the effort that went into Moment and Luxon, which will largely be superseded. Luxon especially is a joy to work with.

Another way of viewing this would be that these and other implementations have paved the way for standardization, which would possibly never have happened without them.

Re: JavaScript Temporal is coming

#104

I 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 thought it was Temporal the workflow engine in the browser

Re: JavaScript Temporal is coming

#105

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.

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…

The operating system is responsible for tracking timezone changes. If you turn off automatic timezone switching or you're in an airplane without internet then the timezone change just won't be detected, which is perfectly fine. That isn't an argument against supporting a timezonechange event.

Every major operating system has had a way to keep track of timezone changes going back over 25 years. This was during the era where most people were on desktops, but now most people are on mobile devices so it's more relevant than ever. Chromium already has a time_zone_monitor service in place, which I linked in a different reply.

Currently, if you want to detect that the timezone has changed you have to poll `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`. An event would just let you get notified without requiring polling.

Updating the displayed time on the client is precisely one of the reasons that this feature can be desirable.

Re: JavaScript Temporal is coming

#106
post #91

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.

FYI, the Moment.js docs recommend not using Moment.js[0]

    > We now generally consider Moment to be a legacy project in maintenance mode. It is not dead, but it is indeed done.
The author spells out a few pitfalls of Moment's design and why they're not addressing these as well as alternatives (Luxon, Day.js, date-fns, js-Joda)

I've switched to Day.js instead[1]

[0] https://momentjs.com/docs/#/-project-status/

[1] https://day.js.org/

Re: JavaScript Temporal is coming

#107

Earlier quoted context omitted.

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.

Not to the same level as back then, the closest thing would be Apple refusing to implement good PWA integration and Web Push Notifications (forcing people to use Apple Push Notifications which only works in Safari). PWAs are still (mostly) supported in Safari, they just don't integrate at the OS level in iOS.

Apple is still actively developing Safari and JSC and implementing standards, Microsoft basically COMPLETELY FROZE browser improvements for 10+ years. Worse even, they pushed proprietary Microsoft-only solutions to try to lock-in people.

Re: JavaScript Temporal is coming

#108

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

in python, 'pendulum' is the datetime swiss army knife. If you havent been using it, you should check it out

I'd suggest `whenever`, which has taken inspiration from Temporal: https://github.com/ariebovenberg/whenever

For Pendulum, I'd suggest folks take a gander at its issue list to see if the bugs reported are 1) real and 2) something you can live with.

Well, when GitHub is back up anyway. Lol.

Re: JavaScript Temporal is coming

#109
post #98

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…

why does the polyfill have dependencies? And it's 200KB alone compared to 60KB of moment.

Did you bother to look at it?

It has a single dependency, and that single dependency has no dependencies of its own.

So what is that dependency?

"temporal-spec"

And it looks like it comes from the same github repo. It basically looks like they broke out the API definitions so that they could be depended on by other potential implementations. This isn't atypical.

Re: JavaScript Temporal is coming

#110

I 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 agree, the naming is unfortunate. DateTime would have been way better.
Post reply on HN