JavaScript Temporal is coming • Hacker News Board

Re: JavaScript Temporal is coming

#311

Post by modeless » Fri, Jan 31, 2025, 1:17 AM UTC

nikeee wrote: post #299

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…

I guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).

Re: JavaScript Temporal is coming

#312

Post by [deleted] » Fri, Jan 31, 2025, 1:23 AM UTC

modeless wrote: post #311

nikeee wrote: post #299

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…

I guess this would require operator overloading. Is there a proposal for that? A JavaScript version of numpy/pytorch would also need overloading (plus array slicing).

[deleted]

Re: JavaScript Temporal is coming

#313

Post by sureIy » Fri, Jan 31, 2025, 1:33 AM UTC

nikeee wrote: post #299

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…

Why not just use 'String()' or '2020-01-01'?

Re: JavaScript Temporal is coming

#314

Post by syncsynchalt » Fri, Jan 31, 2025, 1:34 AM UTC

nikeee wrote: post #299

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…

It looks like `.epochMilliseconds` should work as a Map/Set key/member in some situations, though you'll need to preserve the instant in the value in the Map case if you want to preserve the zonedata / do further operations on the Instant.

For the Set case you could use a Map{v.epochMilliseconds:v} and preserve the Instant.

Not great, but I think we all blame JS for this rather than Temporal. This could be made to work by the runtime but then polyfills would fail.

Re: JavaScript Temporal is coming

#315

Post by sureIy » Fri, Jan 31, 2025, 1:37 AM UTC

ggregoire wrote: post #153

Anyone knows how the data about each timezone stays updated within Temporal? Does the TC39 update the data somewhere, then each browser copies that data internally and releases a new version of the browser? If a user visits my website and this user has not updated their browser with the new data, will they see incorrect hours? For example Mexico removed DST in 2022 [1]. When using third party libraries like pytz or m…

Browsers already have to stay up to date with locales due to the Intl helpers so researching that would likely lead to the same answer.

Re: JavaScript Temporal is coming

#316

Post by sureIy » Fri, Jan 31, 2025, 1:42 AM UTC

wim wrote: post #41

aetherspawn wrote: post #18

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.

> Converting to UTC is lossy

How so? UTC is a constant point in time. The difficulty lies in representing the value correctly, but the point in time is unchanged.

Unlike what sibling comment mentioned, if an appointment is scheduled at 1739287704987, the value will be the same regardless of where and when it's accessed from.

Re: JavaScript Temporal is coming

#317

Post by [deleted] » Fri, Jan 31, 2025, 1:44 AM UTC

stevage wrote: post #277

I've used Temporal a bit with a polyfill. It's a huge improvement. There's no "it's coming" really. With build processes and polyfills there's no reason to to use it already.

[deleted]

Re: JavaScript Temporal is coming

#318

Post by syncsynchalt » Fri, Jan 31, 2025, 1:44 AM UTC

kccqzy wrote: post #181

infogulch wrote: post #157

Does this mean we can finally stop downloading and running a third of a MB of js on every website? moment.js, luxon, date-fns, are all obsolete? https://bundlephobia.com/package/moment@2.30.1

I would start by arguing that not every website needs to deal with dates and times on the client side. And furthermore, if a website only needs to deal with dates but not times (surprisingly common) it can be done in a few KB of JavaScript—the Gregorian calendar is easy compared to the mess of ever-changing time zones and leap seconds.

I'd argue the opposite: APIs should publish all datetimes as UTC timestamps and only the client should be involved in presenting datetimes in the way best suited to the user experience.

I'd also argue that presenting dates in ~0KB of javascript is better and less error-prone than several KB of javascript - it also allows users to see dates in non-Gregorian calendars when they prefer.

Re: JavaScript Temporal is coming

#319

Post by tubthumper8 » Fri, Jan 31, 2025, 2:16 AM UTC

brundolf wrote: post #308

nikeee wrote: post #299

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…

Is there any non-primitive JS type that has non-referential equality for ==?

Yeah, that's one of the core problems, there's no overloading of equals in JS and no other cases of objects using non-reference equality. Adding that in itself would be a big deal (ex. see the Records and Tuples proposal which has been going on for years and may never complete)

Re: JavaScript Temporal is coming

#320

Post by justingrantjg » Fri, Jan 31, 2025, 2:18 AM UTC

sureIy wrote: post #313

nikeee wrote: post #299

I really like the temporal proposal, except for one thing: they rely on reference equality in comparisons. On other words: Temporal.Instant.from('2020-01-01') != Temporal.Instant.from('2020-01-01') This isnt inherently bad, but it effectively removes the ability to use these objects as Map keys or collecting them in a Set. I know why that decision was made, I'm just sad that this wont be possible. Maybe there will be…

Why not just use 'String()' or '2020-01-01'?

Temporal includes `equals` methods on every type. String comparison sometimes works, but there are enough cases where it doesn't (especially when comparing strings that refer to the same data but were generated by different libraries so formatting is different for things like trailing zeroes of decimals, time zone aliases, etc.) that it's usually best to use a library function for comparison instead of just using string comparison.