Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56892
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain inbox.lv designates 89.111.3.83 as permitted sender)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <alpine.DEB.2.02.1112121133490.27751@whisky.home.derickrethans.nl>
Date: Mon, 12 Dec 2011 19:33:22 +0200
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Message-ID: <8D58A664-7250-4FEE-9424-2D2DEFC69308@inbox.lv>
References: <C5AADC70-04B2-4682-9C1B-86BF9E0997AF@inbox.lv> <alpine.DEB.2.02.1112121133490.27751@whisky.home.derickrethans.nl>
To: Derick Rethans <derick@php.net>
Subject: Re: [PHP-DEV] Local time zone
From: chortos@inbox.lv (Oleg Oshmyan)

> 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