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.