Hi Dave! Yep, agreed on all counts. Popular libraries are often stuck with their original behavior forever.
So my advice above (to not canonicalize the user's input time zone identifier to follow links) is much more practical for new libraries, or major versions of existing libraries that are OK to break backwards compatibility. > That's not really the issue for this particular library. I should know, since I wrote it. Oh! Sorry, I misunderstood. So any disruption of TZDB changes is when a user upgrades your library, not when they upgrade the OS. This is a good strategy to make things more predictable for developers. In JS, there's a mix of approaches. JavaScriptCore (Apple's JS engine) relies on the OS's time zone data, while V8 (Google) and SpiderMonkey (Firefox) use a bundled-in approach like you do, as do most 3rd-party timezone libraries in the JS ecosystem so that they can run in browsers where the file system is unavailable. Best, Justin
