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

351–360 of 416 posts

Re: JavaScript Temporal is coming

#351

Post by theplatman »

rimunroe wrote: post #245
nobleach wrote: post #13

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and…

Records and tuples are unlikely to ever ship, or at least are extremely unlikely to ship with the semantics around equality people want. My understanding is that browser vendors already have pretty strong opposition to introducing new primitives at this point. Reading this thread[1] will give some explanation as to the hiccups with how equality would behave. It sucks, because while I wouldn't have expected BigInt to…

BigInt shipped because financial organizations needed it for certain applications.

Re: JavaScript Temporal is coming

#352

Post by makeitdouble »

foobarchu wrote: post #304
michaelcampbell wrote: post #182

Earlier quoted context omitted.

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

Are your production servers configured in something other than UTC, or is there a factor here I'm missing? I've never really seen a good reason for a live server not to be Z'd out

This is grand-parent's point IMO: running your cron on UTC is a decision to have it on that specific timezone.

So you're effectively deciding for instance to send your user newsletter at varying hours, sometimes at 1h00, sometimes at 3h00. Or accept that every scheduled event needs to be appropriately timezoned and adjusted as needed if DST change. Or to have your logs timestamp be non obvious when comparing events separated by months, or have to convert all your business timestamps to a different timezone.

Those are all sensitive decisions, and we usually accept the trade-off, but it needs to be an explicit tradeoff.

Re: JavaScript Temporal is coming

#353

Post by jlarocco »

wlesieutre wrote: post #269
michaelcampbell wrote: post #182

Earlier quoted context omitted.

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

That won't save you everywhere, Greenland falls back at midnight (12 AM Sunday to 11 PM Saturday) in order to synchronize their DST change with Europe https://www.timeanddate.com/time/change/greenland/nuuk

I wonder if that will that change when America owns Greenland /s

Re: JavaScript Temporal is coming

#354

Post by reshlo »

tharkun__ wrote: post #309
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/…

Even countries that are on UTC don't save you from this. I had no idea until very recently but there is a time that simply never existed in Iceland! Wednesday January 2st 1908 00:00 clocks were turned forward 28 minutes to 00:28. So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round and one might think they are the best and easiest country to handle timezone wise. htt…

> So an entire 28 minutes of time never eexisted in Iceland even thought today they are on UTC year round

Those two facts aren’t connected. At the time that those 28 minutes were skipped, Iceland was using the equivalent of UTC-01:00.

Re: JavaScript Temporal is coming

#355

Post by darepublic »

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…

Not all use cases related to time are too complex to just use the existing javascript Date

Re: JavaScript Temporal is coming

#356

Post by jdkoeck »

ivanjermakov wrote: post #325
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…

Because it is impossible in JS? Except some crazy hacks, similar to how Java's constant string pool works, where every used object is a reference to a value in a pool of all objects.

I wouldn’t call this a particularly crazy hack, it’s also called string interning and I reckon that’s what every language runtime does when strings are immutable (which includes javascript runtimes, also this isn’t required by the language specification).

Re: JavaScript Temporal is coming

#357

Post by stevage »

8n4vidtmkvmk wrote: post #341
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.

The big bundle size is a reason.

Is it bigger than the equivalent Luxon or whatever?

Or maybe I'm just fortunate to work in sectors where no one ever really cares about bundle size.

Re: JavaScript Temporal is coming

#358

Post by stevage »

z3t4 wrote: post #37
nobleach wrote: post #13

There are quite a few things marinating in the TC39 pot right now. This is one that I wish would ship sooner, rather than later. I do recognize that it takes dev effort (on the part of v8, JSC, and SpiderMonkey engineers) to get the major browsers to support any of these new features. So I truly appreciate all that folks are doing to move the ball forward. The impatient person in me is cheering, "now get Records and…

It's not just the major browser makers. I was working on a JavaScript inference engine around when ES6 started to roll out, I had decent ES5 support but when all the syntatic updates came I had to give up. They basically killed the JavaScript ecosystem with all the updates. We only have complile to JS languages now. Those that still writes in vanilla JS are like those who still build apps in assembly langauge.

The main reason people don't write much vanilla JS is because they're writing TypeScript instead.

Re: JavaScript Temporal is coming

#359

Post by DanielHB »

phire wrote: post #297
WorldMaker wrote: post #235

Earlier quoted context omitted.

> during the IE5/IE6 era During that era was a peak of browser innovation. IE5 and IE6 contributed a lot of things to web standards. They contributed a bunch of things that web standards eventually rejected too , but that was the risk of innovation at the time. It was the period between IE6's last feature update and IE7's first release where Microsoft declared the browser wars "finished" and disbanded the IE team ent…

I would say the darkest era was after IE7 was released: 2006-2010. You could see all the new features, you could use them, you could design your site around them. But so many people refused to upgrade, so as a web developer you were forced to do stupid things to make IE6 work. And it's not like IE7 was that much better. You needed to put effort into making that work too. At least Chrome and Firefox would usually both…

> And it's not like IE7 was that much better.

The end of the dark ages was when IE9 was released in 2011 which massively improved the browser.

Re: JavaScript Temporal is coming

#360

Post by Capricorn2481 »

Cthulhu_ wrote: post #73
parasti wrote: post #68

Earlier quoted context omitted.

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

> 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

JS doesn't really have breaking changes. Until they do, MomentJS will always work.

> It standardizes it across platforms and implementations

Does it? I mean it prints the date and is a standard library, but I don't think it standardizes anything. Web doesn't really benefit from everyone using the same date library. It's all strings once it's sent over the wire.

Post reply on HN