If you have a time zone picker in your web UI that shows accurate & current time zone abbreviations, there's a good chance it's pulling in 770KB of moment-timezone dependency. And if you were thinking of replacing moment with luxon, this use case would be a potential blocker for shrinking your bundle.

It is surprisingly challenging [and soul-sucking] to work with timezone lore with the goal of reducing this down to something small and fast. There are many performance foot-guns and correctness edge-cases that have to be addressed. With the help of AI (Fable 5 here), this becomes tractable for a single engineer to iterate on in the span of a weekend. I worked through about 12 different prototypes during the process, mixing and matching various strategies and approaches for every aspect of the final result. This should tell you something about how much taste and steering still needs to be applied even to frontier models by an experienced swe to produce something of high production-grade quality, not just, "it works, ship it". If you're familiar with my existing OSS work, I would not ship any level of unaudited slop :) Also, https://github.com/leeoniya/easy-tz/blob/main/comparison.md is not to be missed.

Hopefully one other dev (or agent) finds this useful; I think it fills a missing gap in the frontend timezone-handling ecosystem.

disclaimer: still 0.1.0, so if you use any of the non-default implementations in the lib, expect some turbulence before 1.0.