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.
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 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