On Thu, Feb 20, 2025 at 2:30 PM Justin Grant via tz <tz@iana.org> wrote:
> 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. > That's not really the issue for this particular library. I should know, since I wrote it. The Perl DateTime-TimeZone distribution is a bit unusual among TZ libraries because it actually compiled the IANA TZ DB down to individual Perl modules. It _never_ looks at the installed tz files. Why? I dunno, it made sense to me when I wrote this stuff many years ago. Nowadays, it seems suboptimal, but I'm not going to change it now, and there is a drop-in (for use with DateTime.pm) alternative that just uses the tz files, DateTime-TimeZone-Tzfile <https://metacpan.org/pod/DateTime::TimeZone::Tzfile>. So the problem in this case is a bit different. if you update your DateTime-TimeZone install, you get a new TZ DB, even if your system hasn't changed. > 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.) > It would be possible for DateTime-TimeZone to preserve the name, but AFAICT the issue in the original email was that the actual time zone rules changed. > 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. > At this point I think it's probably too late to make this the default behavior in Perl's DateTime-TimeZone. There is a big backwards compatibility issue in changes here, because it's been the way it is for so long (first release in 2003!). Cheers, Dave Rolsky http://blog.urth.org https://github.com/autarch
