Re: Proposal for Changes to PEAR::Date
| From: | Michael Gauthier | 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
>
>