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

331–340 of 416 posts

Re: JavaScript Temporal is coming

#331

Post by justingrantjg »

mason55 wrote: post #150
Cthulhu_ wrote: post #69

Earlier quoted context omitted.

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.

Here are a couple starting points https://medium.com/servicios-a0/on-solving-the-tzdb-changes-... https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen

> https://github.com/tc39/proposal-canonical-tz - appropriately to these comments, a proposal to handle tzdb changes, built on top of JS Temporal, includes some great examples of all the ways this can happen

Thanks! I was the co-champion of that proposal. Parts of it were merged into Temporal last year, and other parts are already part of the JS Internationalization (ECMA-402) specification here: https://tc39.es/ecma402/#sec-use-of-iana-time-zone-database

Re: JavaScript Temporal is coming

#332

Post by pavon »

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

And time since epoch was defined sanely.

Re: JavaScript Temporal is coming

#333

Post by jwr »

Uninen wrote: post #290
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

moment.js has been obsolete for years . I've considered it as a sign of an unmaintained code for at least ~5 years by now. There has been so many better and lightweight alternatives for years that if you haven't already refactored it away, you just don't care about your users or the bundle size. (And I have personally done that exercise a handful of times myself, I know it can be painful, but it's just one relatively…

> moment.js has been obsolete for years. I've considered it as a sign of an unmaintained code for at least ~5 years by now.

What's wrong with continuing to use moment.js in an application where it works well?

Re: JavaScript Temporal is coming

#334

Post by justingrantjg »

mason55 wrote: post #158
jrochkind1 wrote: post #133

Earlier quoted context omitted.

It does not assume that -- implementing libraries need to -- and do, in practice right now -- implement the rules for jurisdictions change the rules for offsets. That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. All of this is kept t…

> That's part of why they are tied to a certain city -- time zone rules are unlikely to bisect a city, although if they did I guess they'd have to deprecate it as a timezone name and use something else! Not sure if this has ever happened. It's actually easier to create this problem than by bisecting a city, and the easier way is even more complex than bisecting a city. You obviously can't put every hamlet, town and v…

Yep. That said, for end users it's a fairly good story because consumer OSs have gotten very good at automatically adjusting clients' time zone based on geo-location. Just like when you fly to another country and the first thing that happens when you connect your laptop to the internet is you're offered to change your time zone to the local time zone. I assume that the same thing happens when you're in a place whose IANA time zone changes like your America/Punta_Arenas case or many others like it.

Re: JavaScript Temporal is coming

#336

Post by zeroimpl »

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…

Even if that worked, using these in a map/set would be a lot like using floating point numbers in a map/set - which is generally a bad idea.

Re: JavaScript Temporal is coming

#337

Post by 65 »

recursive wrote: post #200
halfmatthalfcat wrote: post #102

Earlier quoted context omitted.

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.

Assignment is already an expression, no? console.log(x = "hello");

Now try it with a constant:

    console.log(const x = "hello");
Doesn't work.

Re: JavaScript Temporal is coming

#338

Post by 8n4vidtmkvmk »

justingrantjg wrote: post #320
sureIy wrote: post #313

Earlier quoted context omitted.

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

Comparison functions are unlikely to work across libraries too?

Re: JavaScript Temporal is coming

#339

Post by 8n4vidtmkvmk »

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

There's exactly one IIRC. document.all

Re: JavaScript Temporal is coming

#340

Post by recursive »

65 wrote: post #337
recursive wrote: post #200

Earlier quoted context omitted.

Assignment is already an expression, no? console.log(x = "hello");

Now try it with a constant: console.log(const x = "hello"); Doesn't work.

That's a declaration. That would be cool. Doesn't currently work with let or var either.
Post reply on HN