Re: Proposal for Changes to PEAR::Date

From: Date: Mon, 12 May 2008 02:31:30 +0000
Subject: Re: Proposal for Changes to PEAR::Date
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-50087@lists.php.net to get a copy of this message
Mason, At work, we have the exact same concerns with the Date package. I would love to see it ported to PHP5 and to use the time-zone methods provided by PHP5. Disclaimer: I am not a PEAR::Date developer or maintainer. Mike On Sun, 2008-11-05 at 21:00 -0400, Mason Malone wrote: > 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 > >

« previous php.pear.dev (#50087) next »