> This might work on some distrbutions, but not nearly on all. And
> definitely not on Windows. On Debian it's not a symlink for example.
It is still usable as one of the possibilities for the guessing algorithm
to examine.
Initially I also wanted to say that /usr/share/zoneinfo can be searched
if /etc/localinfo is not a symbolic link, but I have just run a test:
time { find /usr/share/zoneinfo -type f \
-exec cmp -s /etc/localtime '{}' \; -print; }
and it took 1.5 seconds on openSUSE 11.4 and a second on Mac OS X 10.6
(by the way, on the latter /etc/localtime is a symbolic link). I suppose
it would take less if I only examined paths corresponding to time zones
known to PHP but it would likely still take a long time. Thus this is
perhaps reasonable as optional behaviour (such as
date_system_timezone_guess($try_harder=false) called with true as the
argument) but certainly unwanted in code that executes by default.
> It's a guess, and that's the problem. Guessing makes up for odd and
> strange bugs if it's not 100% accurate (which it isn't).
Which is why a pseudo-timezone called System is needed so that guesses do
not have to be made. The extension would then convert /etc/localtime to
its internal time zone description format or just use system-provided
APIs as it used to do before PHP 5.1 if I understand correctly.
> That's a really bad idea, as we've discussed before on this list.
I can see why it is a bad idea to make such a time zone the default in a
language used mostly for server-side software, although replacing it with
a guess approximating such a time zone as the default, which is what PHP
5.1 did, seems even worse, and it is good to see that PHP 5.4 takes a
better approach. However, I do not see how this is a bad idea for scripts
people run among other software that all uses the system time zone--or
perhaps I should even say 'the system's notion of local time', since
(however uncommon this is) it might be different from any particular time
zone. I have searched in the archive of php-internals and not found any
discussion of this. Perhaps I am a bad searcher; I would appreciate if
you pointed me at some of the past discussion.
--
Oleg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
