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.
JavaScript Temporal is coming
341–350 of 416 posts
Re: JavaScript Temporal is coming
#342Earlier quoted context omitted.
Going back even further in time, Java.util.Date was was heavily inspired by a C library. That’s the origin of getMonth() in Java (and therefore in JS) returning a value from 0-11 and not 1-12 as many coders initially expect. What was the origin for this peculiarity in C? That I don’t know, but I’m curious to find out if anyone knows.
Just spitballing, but in C it was always the convention to use zero-based indexing. Probably because you were often adding these indexes to pointers (literal memory addresses) to index into an array, so you needed a zero to index into the first slot of the array.
What I don't get is why the day of the month doesn't also start at 0?
Re: JavaScript Temporal is coming
#343Very sad that .Now is not a function call. It shouldn't be a property.
Evaluating .Now multiple times in a loop will yield different values, which is unexpected.
C# did the same and it shouldn't have been:
https://ericlippert.com/2014/05/19/when-should-i-write-a-pro...
Re: JavaScript Temporal is coming
#344Carbon is a similar class in the PHP world that's inherited from DateTime. This gives a good description of how working with mutable timestamps can cause problems, because methods like $newInstance = $instance->addDay() modify the original instance and return it, rather than returning a copy that's a day later: https://carbon.nesbot.com/docs/ So it's best to mostly use CarbonImmutable so that a new instance is always…
This has bitten me a couple times too but it's usually easy to figure out the first time you botch it and you're more careful after that.
Immutability is double edged. If I'm doing a bunch of math on a date, I don't want to be creating a dozen copies either.
SQL query builders also have this problem.
Re: JavaScript Temporal is coming
#345I 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
We're definitely bike-shedding a decision that has already been made, but I agree that it's a horrible name. First, "Temporal" is an adjective , not a noun. It might be related to time, but it doesn't make intuitive sense. But more importantly, choosing an odd name because it has a lower probability of conflicting with old code will just make the language increasingly obscure over time. When they added Promise and Ge…
I don't think you create Temporals though. It's essentially a namespace for things like Instant, so it need not be a noun.
Time has the opposite problem. I expect it to be a class, not a namespace. Time.Time creates more confusion, not less.
Re: JavaScript Temporal is coming
#3462024: Nested CSS 2025: Temporal Once we can style 's HTML/CSS/ECMA will be complete. Thank you for everyone's hard work. Let's focus on interop and PWA apis!
I've needed these custom selects so many times... Including right now and I'm dreading building one from scratch again because all the libs I've found are lacking.
Re: JavaScript Temporal is coming
#347There 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…
To be honest, this reads kind of insane, and reminds me of how wasm was at least partially designed around V8 idiosyncrasies and limitations.
Re: JavaScript Temporal is coming
#348Does 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…
Hey now, I'm offended. I maintain my app. I just have better things to do than constantly upgrade and strip away old libs because the JS kids have moved onto the next hottest thing.
Re: JavaScript Temporal is coming
#349Earlier quoted context omitted.
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
> most often if you want to do
most often it is "most often" that causes bugs in software. And when related to date/time it often are severe bugs. ;-)
Re: JavaScript Temporal is coming
#350It feels like temporal has been coming for 15 years.