Interaction with Temporal

[sandstrom]

Would it make sense to make use of Temporal as the underlying date object for this class in the future, when support for it has improved (and the feature has been fully standardized, still stage 3)?

Just wanted to open up a discussion about it, since it may affect various aspects of this library (should people conclude that it's a good route to go down; that may not be the case).

[icambron]

It's a complicated question. On the one hand, Temporal will make many of Luxon's features redundant. I certainly wouldn't want to keep an independent implementation of those features in Luxon.

On the other hand, it will almost certainly make sense to have a library to fill in gaps for parsing, formatting, intervals, and whatever else Temporal is missing. Should that library be Luxon? Or a new library? Sort of depends on the details...

[sandstrom]

Understand, makes sense!

»Wait and see« is probably a pretty good approach here

[sandstrom]

@icambron Just wanted to pick this up briefly :)

Temporal is heading towards Stage 4 (TC39), i.e. it's getting ready to ship in browsers:
tc39/proposal-temporal#1450 (comment)

I think it's a great addition, but API-wise I would still prefer something like Luxon.

Maybe it would make sense to release Luxon 4.x with Temporal as the underlying library?

Basically a opinionated API sugar over Temporal and Intl (anyone who prefer the API of Temporal and Intl could use them directly instead).

Misc things:

• Great with the new website (https://moment.github.io/luxon/)
• Maybe change the org name on Github, to avoid confusion with Moment? For example luxon-org or luxon-team could work. Would be good both for the website and for the repo itself (see Rename Github org #1297).
• There is a polyfill that's basically complete, which could be used in case Luxon want's to switch to Temporal as the underlying Date engine (https://github.com/js-temporal/temporal-polyfill).

[icambron]

I strongly suspect that should just be a new library. It doesn't have to be Luxon.

Here are some thoughts I wrote on Twitter in May: https://twitter.com/luxonjs/status/1522606725345562625

[sandstrom]

Quoting for anyone else reading this thread:

First, Temporal is great and you should use it. So the question becomes, what role, if any, does a tool like Luxon play in in a world where everyone does that?

There are certainly lots of useful things that Luxon does that Temporal does not, mostly conveniences that developers often need when building date-related functionality.
But Luxon's design is pretty specific: it doesn't, chiefly, take in JS dates and spit out JS dates; instead, it constructs an object that holds together the timestamp, the zone, and the locale.

Then the methods hang off that object.>
Temporal does two of those things already, and Luxon's bundling of the locale was, in retrospect, clearly a mistake. (Locales should have come as arguments to individual methods, not packaged as part of the DateTime)

So Luxon's design doesn't really make sense as a way to decorate Temporal with userland features. It was great for Date because date was so broken, it was a sane way to make things like startOf("week") respect the zone. But with Temporal, it would be a no-value wrapper.

For Temporal, a date-fns-like library design makes a lot more sense. It has all the advantages of that approach but not the pain points it has with Date.

So that's all to say that Luxon won't do anything more than add some toTemporal()-type adapter methods and ride into the sunset. If all goes well, in a few years, it will be a distant memory.

[sandstrom]

Thanks @icambron that makes sense!