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

51–60 of 416 posts

Re: JavaScript Temporal is coming

#51

Post by fkyoureadthedoc »

ninkendo wrote: post #22
noduerme wrote: post #15

Earlier quoted context omitted.

The client's timezone should only matter to the client. There's no condition where their clock matters except to translate a timestamp into their local time (for their convenience). Who cares if they change time zones?

So that you can update the UI to show the new time zone? Or change the time format to indicate that it’s no longer in the same time zone as the user is in? That’s just off the top of my head, I’m sure there’s more.

I agree that it would be a nice feature, but I'd really have to be scraping the bottom of the feature barrel before I got to this. Unless my product heavily featured scheduling, or was a clock.

Re: JavaScript Temporal is coming

#52

Post by BoppreH »

noduerme wrote: post #15
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.

The client's timezone should only matter to the client. There's no condition where their clock matters except to translate a timestamp into their local time (for their convenience). Who cares if they change time zones?

Sending emails at specific user times, billing (be careful with this one!), scheduling events in the future, reporting it to other users (Microsoft Teams' "it's 20:39 in this user's Timezone").

Re: JavaScript Temporal is coming

#53

Post by spiffyk »

baq wrote: post #29
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?…

First rule of being a platform: Do Not Break Existing Code.

Well, Java did not break existing code, they added the new code alongside the old one. Just like JavaScript seems to be doing years later.

Re: JavaScript Temporal is coming

#54

Post by dkdbejwi383 »

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…

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

Re: JavaScript Temporal is coming

#55

Post by scarface_74 »

lblume wrote: post #12
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.

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 for me. I could have flown to Seattle for a business meeting and I want to change my DND to local time to be in sync with the rest of the team onsite.

The other scenario is that I’m flying to Los Angeles to hang out. But I’m working during the day and I still need to work east code time.

Re: JavaScript Temporal is coming

#56

Post by klabb3 »

jitl wrote: post #26
noduerme wrote: post #20

Earlier quoted context omitted.

Records.. Wasn't Dictionary an ECMA5 proposal or was that just a novel touch in AS3? [edit: For those who don't know, Dictionary was a type in AS3 that let you use any object reference or string or number as a unique key, with any type of value attached. Garbage collection worked around this so it wasn't a weak reference as long as the dictionary object itself was alive. Think of a Javascript Set except with strongly…

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.

Re: JavaScript Temporal is coming

#57

Post by amiga386 »

tomtomtom777 wrote: post #28
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…

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

+02:00 is not political. It's an offset from UTC and will be the same offset in the past and future.

Europe/Paris is political. It defines that offsets change at certain times of the year, but that could change tomorrow, or the political boundary that the timezone applies to could split such that the person or entity needing a time in their "local" timezone finds another one needs to be picked (see various US states/counties applying/disapplying daylight savings).

It's impossible to be 100% confident what the offset from UTC will be at any time in the future. You also need to be a historian to correctly apply it to times in the past - take https://en.wikipedia.org/wiki/Time_in_the_Republic_of_Irelan... as an example!

Re: JavaScript Temporal is coming

#58

Post by jb1991 »

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.

Re: JavaScript Temporal is coming

#60

Post by bolognafairy »

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.

> Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

…Huh? Are you referring to transpilation?

Post reply on HN