> it ought to continue to mean what it meant > on System V, whether that corresponds to any physical location or > not.
I have no opinion about what Zone the Link EST5EDT should map to. (Although I'd be inclined to avoid changing it unless there's a really strong reason to cause the churn.) But I have a strong opinion that EST5EDT and other deprecated Zone names should remain Link names, because: * The current TZDB policy for merging zones is that they have the same rules since 1970. It would be weird if widely-used Zone names like Europe/Oslo are merged while obscure, deprecated System V names are not. * Every Zone name means more overhead for the ecosystem: more cached strings on devices, more localized strings needed, more user-facing noise in UI time zone pickers, etc. Spending that overhead for long-deprecated names seems like an unwise tradeoff. > > I recently filed a GitHub issue against the perl DateTime::TimeZone library, which uses your database: > > https://github.com/houseabsolute/DateTime-TimeZone/issues/58#issue-2864445920 The core problem you're running into is that this library is eagerly "canonicalizing" (resolving the Zone name for a Link name) its input names. This means that code using this library may change its behavior whenever the host system updates its time zone rules. Current JavaScript implementations have the same problem, which has resulted in previously-working code (e.g. automated tests) suddenly breaking after an OS update. Fear of those breaks has led some JS implementations to refuse to update to modern Zone names. For example, Chrome and Safari will transform Asia/Kolkata inputs to Asia/Calcutta outputs. Same for Asia/Ho_Chi_Minh => Asia/Saigon and Europe/Kyiv => Europe/Kiev. This has caused many years of developer complaints <https://docs.google.com/presentation/d/1MVBKAB8U16ynSHmO6Mkt26hT5U-28OjyG9-L-GFdikE/edit#slide=id.g22181d24971_0_102> . To avoid these problems, JS's new Temporal.ZonedDateTime <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/ZonedDateTime> API will not resolve Link names to Zone names when constructing these objects. If you provide Asia/Calcutta or EST5EDT as input, we'll store* that name and give it back* to the caller if they ask for it. (*Well, we actually return a case-normalized version of the string so that implementations can store a 10-bit index into the ~600 Zone and Link names, so if you provide asIA/CalCUTTA then you'll get Asia/Calcutta back. But capitalization won't change across TZDB releases so this optimization doesn't interfere with the goal of not breaking programs when the OS is updated.) Other libraries like Joda-Time used to canonicalize their inputs, but they stopped doing it for similar reasons as noted above: to avoid churn after TZDB updates. We encourage all time zone library maintainers to do the same thing that JS Temporal.ZonedDateTime will be doing: don't change users' Zone or Link name inputs other than normalizing letter case. This may help the overall TZDB ecosystem be more stable in the face of changes, and will make it less risky for users to update their TZDB data without risking breaking their software. Thanks, Justin
