SBECK-github
commented
5 years ago I considered doing this and have discarded it for several reasons.
1) It introduces the problem of figuring out where the Olson data files live. They live different places in different distros, and especially when you add in non-linux flavors (like Windows, etc.) it becomes necessary to support code that is NOT dependent on the Olson data files. So in effect, you are asking me to support two different ways of figuring out timezone data... use the Olson files if they are there, and if not, use some other (i.e. the current) method. If I had infinite amount of free time, I might be willing to consider this (even though I find the duplicate methods somewhat distasteful). Given the fact that I actually do not have nearly enough time to work on all of the perl module tasks that I want to, adding a second timezone method is REALLY low priority.
2) Even if I did this, then what you're asking is that every time you make use of the Olson data, you have to wait while Date::Manip interprets the data. In order to improve performance, Date::Manip comes with the Olson data already pre-parsed. All of the necessary indexes are created so I know where to look for the data. All of the necessary regexps to parse timezones are pre-generated. All of the critical dates (dates where time changes occur) are precalculated. The scripts I use to do all of this calculation take several minutes to run. If I have to do that live (i.e. when Date::Manip is loaded), it will take several minutes to start up any script with a "use Date::Manip" line in it. Although it is possible (even likely) that this overhead can be reduced by a significant amount (seconds rather than minutes), I'm always looking for ways to improve Date::Manip's performance, and adding a potential 10-15 second overhead step is the wrong direction. I could of course write an .xs extension so this was done in C rather than perl (which would reduce the overhead drastically)... but I'm not interested in that at all. I like programming in perl. Not so much C.
So, although I understand what you're asking (and have even explored this option myself), at this point I'm afraid it's not on the horizon.
I know you've stated that you would not like to support TZ files in Date::Manip doc. But I would still like to bring this thing up.
I raised a similar ticket to DateTime::TimeZone https://github.com/houseabsolute/DateTime-TimeZone/issues/33
I believe it's a common thing in Enterprises, that Linux systems /usr/share/zoneinfo can be well kept up-to-date, while a deployed Perl code might not easily get its dependencies updated. In this case the CPAN package bundled Olson data could become outdated over time and cause problems. So it's best if the Perl timezone library can provide a way to allow user to use OS platform's Olson data like /usr/share/zoneinfo.