> I suggest you lobby distributions that bundle PHP to add a post-install > script for "dpkg-reconfigure tzdata" to drop a datetime.ini file in > /etc/php5/conf.d with as contents "date.timezone=<newly selected > timezone>".
This is a good idea (or perhaps exactly the opposite, as I explained in my previous email, but still needed if PHP drops all and any support for system-provided local time), but sometimes people use local copies of PHP instead of system-wide ones or their systems do not come with PHP at all. > Using the information from /etc/localtime is *not* enough as > you can't get the timezone identifier out of it. The time zone identifier would be System. No need to extract one from /etc/localtime. > That will never happen. The whole idea with the new support is to get > *away* from OS idiosyncrasies and not adding more of them! PHP needs to > be able to rely on its own bundled timezone database. Parsing files on > the filesystem is slow and silly. Why is it bad to have this as added functionality? Why are you worried about PHP's ability to rely on its own bundled time zone database? Let me explain my idea once again: I propose **leaving all existing functionality alone** and **adding a new time zone** called System. * All existing time zones will work as they do in PHP 5.4 RC3. The internal time zone database will be used, the internal timezone-aware code will be used and the system will not be consulted at all. Any PHP code using existing time zones will remain perfectly portable across all PHP installations. * date_default_timezone_get will work as it does in PHP 5.4 RC3. Perhaps there is confusion because I initially proposed restoring the guessing algorithm, so let me make this clear: this is a separate suggestion. So, once again: date_default_timezone_get will work as it does in PHP 5.4 RC3. * There will be a new time zone called System. When this time zone is active, instead of PHP's internal time zone database and timezone-aware code, system-provided local time APIs are used. In previous emails, I said things like 'system-provided local time description and/or APIs' but they seem only to increase confusion, so let me drop that part. This System time zone will obviously have some system-dependent behaviour, share the system's idiosyncrasies etc. but this is *the whole point*: if the programmer wants them, they should be able to get them. We have two extremes: portability across systems and blending in with the current system; just like there are two extremes in GUI design: the same GUI being used on all platforms is good because users of the software can freely switch between platforms, but having the common look and feel of the platform the software is running on is good because users of the platform feel at home. PHP's time zone functionality currently forces the programmer to be at the portability extreme; my suggestion is to let the programmer choose which extreme to be at. (The reasoning for 'system-provided local time description and/or APIs' was that it might be easier to implement some functions by converting /etc/localtime to PHP's internal representation and using PHP's existing internal timezone-aware code than by making a new code branch that calls into the system. As for restoring the guessing algorithm, I suggested that merely as an easier alternative to making a whole new time zone that consistently uses system-provided APIs.) -- Oleg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
