ryzokuken

Temporal does in fact conform to standards like ISO 8601 for serialization/parsing etc.

It's been WIP for a few years now! It's easily one of the largest changes to the stdlib of JavaScript recently, and things like these take forever to standardize.

The Temporal API is immutable, so you won't have to deal with it anymore.

because Temporal is not currently used anywhere (as far as we noticed) and it won't break anything while still being descriptive.

Temporal.now.absolute().getEpochNanoseconds()

Not the core API, but a simple custom timezone can be used to implement TAI. I worked on a POC for it, but you can totally test this with the polyfill right now.

https://github.com/ryzokuken/temporal-tai

They are!

Date is "broken" in that it aged pretty poorly, has a very non-ideal API surface and exposes developers to a number of footguns, that could, ideally, be avoided.

The fact that a vanishingly small percentage of JavaScript developers use Date for non-trivial applications is a great indicator of these failures.

It's been WIP for years now. Just takes a lot of time to standardize something like this, you know...

> I am curious though, is there a reason not to just essentially duplicate the Joda[0]/Java[1]/ThreeTen[2] API?

They're definitely an influence, just not the only one.

> LocalDateTime

That's a strawman proposal that's essentially user feedback and not a part of the API. Not yet atleast.

Not yet, but fingers crossed, it would reach Stage 3 in a few months.

As a matter of fact, I have been using Manjaro right now. Thanks for clarifying that Arch does infact beat other distros in terms of speed.