JavaScript Temporal is coming • Hacker News Board

Re: JavaScript Temporal is coming

#181

Post by kccqzy » Thu, Jan 30, 2025, 4:37 PM UTC

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.

Re: JavaScript Temporal is coming

#182

Post by michaelcampbell » Thu, Jan 30, 2025, 4:37 PM UTC

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…

> Otherwise you'll get a bug twice per year due to DST

Those of us of a certain age learned long ago never to schedule cron (etc.) jobs in a production environment between 01:00 and 03:00 local time.

Re: JavaScript Temporal is coming

#183

Post by Larrikin » Thu, Jan 30, 2025, 4:38 PM UTC

moi2388 wrote: post #66

AndrewStephens wrote: post #61

Earlier quoted context omitted.

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

Because it makes the lives of every single person harder to make lazy programmers jobs easier. That's the only reason to do that.

Re: JavaScript Temporal is coming

#184

Post by huskywall » Thu, Jan 30, 2025, 4:40 PM UTC

Oh wow, I was complaining about working with dates in JavaScript around 2010 or so. It only took 15 years to sort this out.

Re: JavaScript Temporal is coming

#185

Post by pknerd » Thu, Jan 30, 2025, 4:44 PM UTC

Umm..I am not sure how the Islamic/Hijri calendar gonna work. Tomorrow is the first Shabaan in Pakistan but it is still 30th Rajab in Saudia. How will JS figure this difference out?

Re: JavaScript Temporal is coming

#186

Post by TheRealPomax » Thu, Jan 30, 2025, 4:45 PM UTC

Will this finally have a proper datetime formatter, too?

Re: JavaScript Temporal is coming

#187

Post by moffkalast » Thu, Jan 30, 2025, 4:48 PM UTC

huskywall wrote: post #184

Oh wow, I was complaining about working with dates in JavaScript around 2010 or so. It only took 15 years to sort this out.

Well assuming this actually sorts it out, which remains to be seen.

Re: JavaScript Temporal is coming

#188

Post by yread » Thu, Jan 30, 2025, 4:50 PM UTC

evilduck wrote: post #136

yread wrote: post #98

Earlier quoted context omitted.

why does the polyfill have dependencies? And it's 200KB alone compared to 60KB of moment.

If payload size is the top concern you shouldn't be using Moment either though. Luxon and DayJS are both considerably smaller (their uncompressed size is about what Moment's compressed size is) and the date-fns library is much, much smaller and also tree-shakeable. Moment also performs at or near the bottom of all available options if speed is a concern. Other than reflexive popularity or the cost already being paid…

Exactly. I should've written even compared to moment

Re: JavaScript Temporal is coming

#189

Post by lostemptations5 » Thu, Jan 30, 2025, 4:53 PM UTC

270 pages of documentation -- wonderful! /s

Re: JavaScript Temporal is coming

#190

Post by ARandumGuy » Thu, Jan 30, 2025, 4:53 PM UTC

Pikamander2 wrote: post #166

> working with dates and times in JavaScript will be hugely simplified > To help you get up to speed, there are over 270 pages of Temporal docs on MDN Not that I'm complaining about extensive documentation, but seeing these two lines juxtaposed doesn't inspire much confidence.

MDN docs tend to be very thorough and well-written. It looks like most of these pages are for various utility functions, each of which has its own page.