I made Luxon 10x-100x faster for +10% minified bundle size.

[leeoniya]

Hello!

This will be a long post, but none of it has been AI written or AI edited, so please don't auto-dismiss it as vibe-slopped junk.

First, I want to say thank you for creating and maintaining Luxon, @icambron, @diesieben07 ❤️. imo, Luxon carries the unique distinction of being correct for time zone and DST math, while every other lib either lacks support or has dozens of long-standing, unaddressed correctness bugs.

Next, I'd like to establish a bit of trust since that seems to be all that will separate the Eternal September of OSS contributions in 2026 and onward.

I'm a frontend engineer at Grafana since 2020, but have been doing frontend OSS for more than a decade before that; my first contribution was improving CSS for QUnit's test reporters :). I've always been motivated to eliminate dependencies, shrinking bundle size, and maxing out what's possible for frontend performance; I author and maintain some popular libs with these priorities on full display. Additionally, I have non-zero experience with time zones, DST, and datetime formatting, both before AI entered the scene, and after:

• rewrite DST handling leeoniya/uPlot#1072
• https://github.com/leeoniya/easy-tz

The effort I'm going to describe here was done over the course of multiple weeks, working with several frontier AI models, iterating countless prototypes and permutations, continuous refinement, hands-on de-sloppification, and curating away bad ideas. This task would have easily taken months (or longer) if I were to do it by hand with a profiler and debugger; in other words, it would not have happened at all. You can see the most recent history of this work on my perf-patches branch, though it started earlier in the easy-tz repo (linked above).

The background to this work is that I've long wanted to replace Grafana's moment + moment-timezone dependencies with something smaller, faster, and maintained: Luxon is ~75KB that could replace ~1.1MB. The thing I discovered soon after starting is that we would lose correct time zone abbreviations in our TimeZonePicker and UI, so I wrote easy-tz. It then further grew to support a limited historical database back to 1995, so that it can be used to extend Luxon's IANAZone class for tz offset and abbr finding. easy-tz is currently ~28KB. Together with Luxon, I was able to get full parity and pass all our existing tests: [PoC] Chore: Swap moment for luxon.

Once the tests were green, I moved on to evaluating performance parity of the proposed swap. We use moment for batch-parsing (date strings from query responses) and batch-formatting (data CSV output). These datasets can be very large, so eagerly processing 20k timestamps or datetime strings is not merely an edge case. What the performance profiles showed was multi-factor regression compared to moment & moment-timezone. So the next step was to accelerate Luxon beyond what an easy-tz-backed IANAZone could provide on its own (which is surprisingly a lot!).

The result of this work is a series of 10 patches (approx 0.8KB min each) which make Luxon not only massively faster than master, but faster than moment-timezone, and in most cases several times faster than even bare moment. Speedups of 10x are typical, and several fixed cache-miss bugs yield as much as 100x.

How? Nothing too clever, just a lot of meticulous work and iteration.

• Avoid Intl whenever possible (pure date math, probe & cache DST transitions cheaply)
• If Intl is necessary, cache it
• Don't redo perf-heavy work within the methods
• Avoid object copies, spreads, allocations
• Add common-case fast paths
• Compile formatters rather than routing through huge switch-case at runtime

The overall size of the minified bundle (non-gzipped) grows by 8KB (+10.5%)

All existing Jest tests pass, and numerous additional assertions were added for tricky TZ and DST edge cases that guard the date math which replaces expensive Intl calls and construction.

At one point well into this work I found the Roadmap for Luxon 4 discussion that mentioned performance not being a serious consideration of the original Luxon implementation, and something that needed to be addressed. I noticed there were benchmarks and a cache added 2 years ago but it was rather limited in scope.

I would love to have as many of these patches upstreamed (1 PR per patch) and additional tests accepted here because it's not realistic to keep this 10-patch stack in sync with this repo (I had to sync it with latest changes just yesterday 😅). I also think Luxon on its own should be ultra fast for everyone. My nightmare would be having to make Grafana run its own fast-luxon fork that will become an unmaintained liability if I ever meet my premature demise at the front of a bus.

I realize that reviewing these PRs will be a significant time investment from the maintainers, but perhaps less than the effort spent so far on proving out this path to something that can feasibly be considered for inclusion.

attached here is the output of cd benchmarks && bun run upstream: upstream-bench.html

What do you think?

ty! <3