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

111–120 of 416 posts

Re: JavaScript Temporal is coming

#111

Post by CharlieDigital »

halfmatthalfcat wrote: post #102
dkdbejwi383 wrote: post #54

Earlier quoted context omitted.

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.

It's going to end up looking a lot like C# [0][1]; these two/three (JS/TS, C#) languages have been converging for a while now. Now just waiting for C# to get official first party discriminated unions!

[0] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

[1] https://timdeschryver.dev/blog/pattern-matching-examples-in-...

Re: JavaScript Temporal is coming

#113

Post by decatur »

With any new DateTime object in any language I usually look at its persistent fields to judge what the memory and access characteristics are.

In case of Temporal it looks like that Chrome goes the JavaScript Date way as it only holds the timestamp:

extern class JSTemporalInstant extends JSObject { nanoseconds: BigInt; }

And then calendrical fields are computed on the fly. Is this correct?

Re: JavaScript Temporal is coming

#115

Post by cosiiine »

manbitesdog wrote: post #92

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

There's even the concept of "Temporal Dead Zone" in Javascript already which describes the period of time where variables aren't accessible.

Re: JavaScript Temporal is coming

#116

Post by tomhallett »

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.

Your example of “New X” is spot on, because there was a timezone with that name, “US/Pacific-New”, which was different than “US/Pacific”. Bit of history: it was added to some timezone libraries because there was a bill in congress to add it, but it never passed. I had to fix a bug because users were getting set with that timezone and then other systems/libraries were barfing on it…

https://github.com/moment/moment-timezone/issues/498

Re: JavaScript Temporal is coming

#117

Post by ko27 »

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?

Temporal API is far more consequential than what was attempted before. Their proposal for serializing timezones is about to become the de facto standard extension to ISO 8601 (date/time).

Re: JavaScript Temporal is coming

#118

Post by roywashere »

phiresky wrote: post #70
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/…

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

While this is true, most often if you want to do "now plus a month" you'll mean "at the same time on the local clock", and disregarding timezone changes, while most often if you want to do "now plus four hours" you'd actually mean four real hours, and you want to calculate in the DST changes to make sure you have four actual hours in your duration

Re: JavaScript Temporal is coming

#119

Post by [deleted] »

rakatata wrote: post #35
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?…

I think they thought they could get away with a hotfix like Intl.DateTimeFormat()

[deleted]

Re: JavaScript Temporal is coming

#120

Post by lttlrck »

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

Just add "What Three Words" for time.
Post reply on HN