hi, On Thursday 27 March 2008 10:26:57 pm Richard Lynch wrote: > Just recently, somebody wondered why PHP had the CORRECT time when > their web-server didn't...
and vice versa. see for example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=471104
if there were an *option* for php to use the system-bundled timezone database,
then this would be a moot point.
but instead, at this point to solve the problem someone will need to go
digging through cvs, produce a changeset, possibly massage the patch to apply
to an older release, ensure the software builds correctly, test the new
packages locally, create a new official release for the stable distribution,
wait for the users to get the update...
this is a process that has been done once already for the system timezone
database packages, why do it again for php? if the admin is using the
packaged versions of php (and that is the point of this discussion), it won't
magically fix itself... so *something* has to be upgraded. and either way
they're usually running "$packagemanager upgrade", taking whatever is new,
whether it is just the timezonedb or the php packages too. it's merely a
question of "get the updates for free?" vs "get the updates when the system
*and* php has been updated?"
> As I understand the situation, if you can get ALL the sysadmins of the
> world to update their [bleep] timezonedb frequently, PHP can drop the
> internal timezonedb.
usually that's a matter of "$packagemanager upgrade" but i digress.
of course if you're in a hosted environment where you've built your own php
but don't have root to update the system timezone db, then it can be very
useful to have the bundled timezonedb too.
but ultimately, what may be best for you may be least optimal for someone
else... so why not provide an option to work both ways? i'm not even asking
that this be made the default, in case you're worried about the clueless
user/sysadmin factor.
sean
signature.asc
Description: This is a digitally signed message part.
