On Thu, 10 Jan 2008, Joe Orton wrote: > On Wed, Jan 09, 2008 at 09:03:02PM +0100, Derick Rethans wrote: > > On Wed, 9 Jan 2008, Joe Orton wrote: > > > > > It's a bit of a maintenance headache for distributions when > > > packages include their own copy of the timezone database, since this > > > needs to be updated frequently. > > > > There is a PECL extension to provide those updates: > > http://pecl.php.net/package/timezonedb > > It is a drop-in replacement to update the rules.
<snip> > I'm not sure I find the logic of the "but the system-provided data will > become stale" arguments convincing; systems which are left unmaintained > by the administrators will have old versions of software on; that's a > given. I can't see why adding *more* packages (PECL timezonedb) which > those admins have to keep up-to-date will make any difference to that. But for the admins who *do* update it doesn't really matter whether there is one or two packages as both should show up when he requests a "list of packages for which updates are available". <snip> > > > 1) I've not implemented timelib_timezone_builtin_identifiers_list() here > > > since it doesn't seem to be used, is it there for third-party > > > extensions? It could be implemented by iterating through the directory. > > > > It's not used (anymore). However, there is a PHP function > > timezone_identifiers_list that uses the index information to enumerate > > all entries. Your patch prevents this function from working as both > > struct elements index_size and index are set to 0/null. > > OK, fixed in attached patch. This is a fix that scans the whole directory - which is not really fast. I find this an unacceptable action to cripple to PHP. > > > 2) there's no general way that I can find to obtain the database > > > version, so I just invented a string here. > > > > Not having the version creates another problem, as the PECL timezonedb > > extension will then *always* override the builtin database. The > > extension uses the version number to see if the extension provides a > > later rules set. With your patch, this extra check will not work > > correctly anymore if PHP's built-in version is newer (which would happen > > if PHP got upgraded). > > This seems fine, even desirable. Anybody who configures PHP > --with-system-tzdata *and* installs the PECL timezonedb always gets the > data provided by the timezonedb; the risk of stale timezone data is > little different to the current risk. However, how does the user know he can actually get a newer ruleset if he does not have any way to see which database is currently active? Not being able to see which version is currently active is yet another degeneration of PHP's timezone functionality. > > - This patchs allows accessing any file on the filesystem (because the > > path is not sanitized). > > Fixed in attached patch. I take your word for that, but I did not test it. > > - Opening a file is less quick than having the data in memory. > > Sure, this is a trade-off; it's configurable exactly so that users get > to make the choice. No, users don't get this choice because it is not them who install PHP - it's the admins. By degrading performance by forcing filesystem reads you're not helping PHP users at all. It's quite similar to forcing only the 1970-2038 range for timestamps to make it compatible with Windows in older RHEL releases. > > - The system's format of tzfiles does not necessarily have to be the > > same as the one that PHP reads. On my (Debian) system the tz provided > > data is already 64bit read. Once I update the extension to use this > > extra data, reading the system tz files won't work anymore. > > I'm not sure exactly what the concern is here; the 64-bit TZif2 format > is backwards-compatible with the TZif format and the existing PHP code > reads it without problems. (I've been testing against it) Ok, good - i wasn't totally sure here. However, like I mentioned in my other mail, the TZif format is not the best way *for PHP* to access the rulesets, and there is the possibility that while building the data the format might change to make it easier to access rulesets for PHP. In that case you can't simply switch the parsing to the system provided database because the format will be different. This is at the moment hypotetical though. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
