Live data from Hacker News

JavaScript Temporal is coming

developer.mozilla.org

61–70 of 416 posts

Re: JavaScript Temporal is coming

#61

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

And lived on a flat planet.

Re: JavaScript Temporal is coming

#62
post #4

If the time zone handling can be added like Golang time package, that would make it very convenient.

that'll work as soon as everyone in the world agrees to download the latest version of their favorite web browser each time Western Sahara is reclassified

We are anyways discussing the future :)

Re: JavaScript Temporal is coming

#63
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…

> First JavaScript is unfortunately not just for web apps. It’s also for desktop apps.

A bit of a tangent but I’d say server is bigger than desktop. Like it or not JS (or TS) is the only cross platform development language that’s feasible today if you want to use a single language stack. As much as I despise the JS ecosystem practices and haphazard tooling there is no point trying to put the genie back in the bottle.

Re: JavaScript Temporal is coming

#64
post #3

Relevant XKCD : https://xkcd.com/2867/

Well I failed one interview because to calculate number of days in between I suggested substracting Unix timestamps and dividing the difference by 86400.

Is there a problem with that or were the interviewers just being stubborn?

Re: JavaScript Temporal is coming

#65
post #58

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.

[deleted]

Re: JavaScript Temporal is coming

#66

Earlier quoted context omitted.

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

And lived on a flat planet.

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

Re: JavaScript Temporal is coming

#68
post #58

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.

Why is it extraordinary? moment.js has been excellent for me, same for PHP's builtin DateTimeImmutable. What does this do that makes it extraordinary?

Re: JavaScript Temporal is coming

#69

Earlier quoted context omitted.

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

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.

Re: JavaScript Temporal is coming

#70

Earlier quoted context omitted.

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

That but also and for me more importantly it does not tell you how to add time - If you add one month of hours to a date in October, it depends on the timezone whether you will end up one hour of local time earlier or not (due to DST), because then +02:00 might be +01:00
Post reply on HN