The Earth still refuses to orbit in a clean multiple of its own rotation, and don't get me started on the Moon, who is just off doing its own thing. The ticket to sort it all out has like a zillion upvotes but they just ignore my pull requests altogether.

Luxon 3.4.4 released, with the big addition of localized week and weekday support

Advice needed. Let's say your team is full stack, and a talented, experienced engineer joins, but he's only done backend work. You want to train him up, everything from HTML/CSS to TS and React and all the toolchain craziness that comes with it. How? Is there, like, a book?

My number one date api request is to give me the offset in seconds instead of minutes

Luxon 3.4.0 is out!

The yearly dance of DSTs is always fun, for some definition of fun

Luxon 3.3.0 has been released, and it loves you.

Is that a git conflict marker or are you just a deeply nested generic type param?

Every time someone hassles me about not being adequately responsive on OSS work, I spend the next two days ignoring Github.

Luxon security advisory:

Luxon 3.2.0 released

Hi, it's Luxon, your friendly local datetime library, back from a nice offline break. How's everything been? Swell, I take it?

Luxon 3.0.4 released. Get it while it's still fresh from the oven, for extra delicious time and date functionality.

Luxon 2.5.0, 3.0.0, and 3.0.1 released in quick succession

Luxon 2.4.0, now with support for the ISO zone extension

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.

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

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)

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.

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.