Proposal for Changes to PEAR::Date

All, I recently decided on using the PEAR::Date package for our company website, but there are some issues that make it a poor fit for us. Specifically, we try to make all our code E_STRICT compliant, but almost any usage of PEAR::Date results in a large number of strict standards notices, which is a result of it being PHP4-compatible. Also, the huge $_DATE_TIMEZONE_DATA array it loads every time Date.php is included eats up a considerable amount of memory. I'd like feedback on the following proposed changes to address these issues. If we can come to an agreement, I'll ask my supervisor for permission to implement them. 1) Migrate entire package to PHP5. As many of you know, PHP4 has been discontinued and there will be no more updates to it, security-related or otherwise, after August 8 (see http://www.php.net/archive/2008.php#2008-01-03-1), so I think it's a good time to drop PHP4 support. Also, the release of PHP6 is in sight, and supporting all three major versions of PHP is going to be impractical if not impossible, as I understand it. 2) Add an option to not load the $_DATE_TIMEZONE_DATA array and instead use the built-in PHP 5 DateTimeZone class for getting timezone data. However, I'm not really sure if this is feasible, since I can't figure out how DATE_TIMEZONE_DATA was generated. Keys such as 'longname' and 'dstlongname' do not appear to have any basis in the latest zoneinfo database. If I'm missing something, please tell me. Otherwise, I can take the additional metadata that can't be found using DateTimeZone and store it in a separate array (generated from $_DATE_TIMEZONE_DATA at packaging time), which would only be loaded when the aforementioned option is turned on. Some lazy loading functionality will be incorporated so loading of the array will be deferred until it's needed. Let me know what you think of these changes, and thanks for your time. -- Mason Malone Software Developer Gleim Publications