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

71–80 of 416 posts

Re: JavaScript Temporal is coming

#71

Post by klysm »

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…

I’m also using it in production and it’s so much better than any of the existing alternatives

Re: JavaScript Temporal is coming

#72

Post by jitl »

Cthulhu_ wrote: post #69
amiga386 wrote: post #57

Earlier quoted context omitted.

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

A timezone changing or being eliminated doesn’t erase the history of that timezone. So you can still use the last definition of such a timezone if the date is still in the future, or use the appropriate definition of the timezone at the time of a date marked in the past.

Re: JavaScript Temporal is coming

#73

Post by Cthulhu_ »

parasti wrote: post #68
jb1991 wrote: 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?

It standardizes it across platforms and implementations; I mean you mention Moment.js, but it's been superseded by Luxon and DayJS ages ago; Moment is very large in terms of file size and doesn't support tree shaking, it creates mutable objects, same as Date, etc etc etc.

But there's the problem. Use momentjs today and you're behind the times, but use the new standard library date functions and you're pretty much guaranteed that code that works today will still work in 20 years.

Re: JavaScript Temporal is coming

#74

Post by deltarholamda »

jb1991 wrote: 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.

It is great news. I was not aware this was in the works.

Using other libraries for something as fundamental as this always seemed odd.

Re: JavaScript Temporal is coming

#75

Post by Cthulhu_ »

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.

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 applications will just use UTC; local timezone is more used to adjust the displayed time, and even then it's opt in (e.g. someone reading a log will want server time or UTC, someone using a calendar will want to see their local time OR the time at the location of an event, etc).

Re: JavaScript Temporal is coming

#76

Post by undebuggable »

blharr wrote: post #64
undebuggable wrote: post #36

Earlier quoted context omitted.

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?

I understand the interviewer wanted to approach the problem as non decimal number of months in a year and variable number of days in a month. One day as the most granular entity. I didn't even wanted to argue over leap years and why the year 1900 wasn't one. It was consecutive meeting in a row and I was too tired for his shit.

Re: JavaScript Temporal is coming

#77

Post by Cthulhu_ »

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.

That's fair, but they didn't need to - just make a new Date library and deprecate the old one.

Re: JavaScript Temporal is coming

#78

Post by Cthulhu_ »

nejsjsjsbsb wrote: post #6

Coming but only available in one browser or run time, and then with a feature flag.

Time and timezones are a big and complicated thing, I'm not surprised / appreciate they're taking their time with it. A library is temporary (ha) and is often superseded (e.g. momentjs -> luxon -> dayjs), but standard libraries are in it for the long time (Date has been around for 30 years and will be around for another 30 alongside Temporal).

Re: JavaScript Temporal is coming

#79

Post by TheAceOfHearts »

small_scombrus wrote: post #48
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.

> They should add an event to detect when someone changes timezones. That sounds like it would be used as yet another data point with which to fingerprint and locate people ._.

I don't believe adding this event would represent a new data point for fingerprinting because it's already possible to detect timezone changes by polling `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`.

Re: JavaScript Temporal is coming

#80

Post by jitl »

SonOfLilit wrote: post #33

Can someone who's been following this explain why they're designing a new API instead of merging one of the successful open source APIs into the standard?

There are plenty of very popular libraries that are low quality and/or have some major issues, popularity of a package is not necessarily indicative of a perfect design. When you put something into your language standard to be supported for the next 30 years you want to make sure it’s as correct for as many people as possible. “Oh this seems to work fine let’s merge it” is not a high enough bar.

It’s inspired by JodaTime which got “merged” into Java, so you could say they are actually just merging an open source project, it’s just not one of the common JS ones.

Post reply on HN