Description: ------------ Consider looking for the DateTime extension, and using that functionality to get an up to date set of information on timezones; falling back to the current method. This could be neatly implemented as a Date_TimeZone_DataProvider // interface Date_TimeZone_GenericProvider Date_TimeZone_DateTimeProvider Date_TimeZone_UnitTestProvider We have: http://au.php.net/manual/en/function.timezone-transitions-get.php http://au.php.net/manual/en/function.timezone-abbreviations-list.php ... which make this seem feasible. This will also stop the slow trickle of: Bug #14769 Bug #14389 Bug #14148 and lots, lots more.

Wouldn't it be better to implement an easier way to keep the Time Zone information up-to-date in the PEAR Date code directly? (For example, one of the PEAR Date developers can run a script that rebuilds a certain PEAR Date PHP file from the new PHP v5.1+ core DateTime extension each time there is an update.) This way the Time Zone information and implementation would not be inconsistent for PEAR Date if it is being run on PHP v5.1+ versus being run on PHP < v5.1.

Perhaps; but if there's one thing that people will forget to do on a 3 monthly basis; it's update the Date package in such a way.

Time Zone rules typically do not update *that* often, do they (particularly for a specific country)? My main concern would be converting from a USA time zone to UTC, then from UTC to another USA time zone. Most users wouldn't care when a time zone rule changes in a country that is not part of their app's user base. For instance, I would know when USA time zones are scheduled to be updated, and therefore would know to update PEAR Date (if I am not doing it on a regular basis anyway). Meanwhile, maintainers of applications that *are* used internationally would be able to keep their time zone rules up-to-date constantly.

http://pecl.php.net/package/timezonedb - releases, very frequently.