Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56917
Return-Path: <derick@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 70045 invoked from network); 14 Dec 2011 10:26:12 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 14 Dec 2011 10:26:12 -0000
Authentication-Results: pb1.pair.com smtp.mail=derick@php.net; spf=unknown; sender-id=unknown
Authentication-Results: pb1.pair.com header.from=derick@php.net; sender-id=unknown
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
X-PHP-List-Original-Sender: derick@php.net
X-Host-Fingerprint: 82.113.146.227 xdebug.org Linux 2.6
Received: from [82.113.146.227] ([82.113.146.227:46237] helo=xdebug.org)
	by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP
	id 61/30-02613-2C978EE4 for <internals@lists.php.net>; Wed, 14 Dec 2011 05:26:11 -0500
Received: from localhost (xdebug.org [127.0.0.1])
	by xdebug.org (Postfix) with ESMTPS id 5264EDE13E;
	Wed, 14 Dec 2011 10:26:08 +0000 (GMT)
Date: Wed, 14 Dec 2011 10:26:08 +0000 (GMT)
X-X-Sender: derick@whisky.home.derickrethans.nl
To: Oleg Oshmyan <chortos@inbox.lv>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <1C397FE3-76E2-473B-B47F-194DAF3ACB39@inbox.lv>
Message-ID: <alpine.DEB.2.02.1112141019110.27751@whisky.home.derickrethans.nl>
References: <C5AADC70-04B2-4682-9C1B-86BF9E0997AF@inbox.lv> <alpine.DEB.2.02.1112121133490.27751@whisky.home.derickrethans.nl> <8D58A664-7250-4FEE-9424-2D2DEFC69308@inbox.lv> <alpine.DEB.2.02.1112131302110.27751@whisky.home.derickrethans.nl>
 <1C397FE3-76E2-473B-B47F-194DAF3ACB39@inbox.lv>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Local time zone
From: derick@php.net (Derick Rethans)

On Tue, 13 Dec 2011, Oleg Oshmyan wrote:

> >> 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.
> > 
> > <snip>
> > 
> >> Perhaps I am a bad searcher; I would appreciate if you pointed me at 
> >> some of the past discussion.
> > 
> > http://marc.info/?t=119988823700001&r=1&w=2 is what it was I think.
> 
> Thanks. The thread was an interesting read but my suggestion is different
> from the one discussed there: I propose adding _one_ special time zone
> that will use the /etc/localtime file or system-provided APIs (only that
> time zone!), not using the /usr/share/zoneinfo directory instead of the
> built-in time zone database. So existing code would work just as before
> but in addition one could write

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>". Using the information from /etc/localtime is *not* enough as 
you can't get the timezone identifier out of it.


>     date_default_timezone_set('System');
> 
> and get direct access to the system's own notion of local time, so e. g.
> 
>     date_default_timezone_set('System');
>     echo date('r');
> 
> would be equivalent to the C code
> 
>     char date[256];
>     time_t now = time(NULL);
>     strftime(date, 256, "%a, %d %b %Y %H:%M:%S %z", localtime(&now));
>     fputs(date, stdout);

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.

> Finally, a word on removing support for the TZ environment variable in
> particular: once again this makes good sense for server-side software but
> is bad for client-side software, as TZ is a standard way of telling
> software you launch which time zone you want it to work in.

TZ key values are not identical among operating systems, so that doesn't 
work.

cheers,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug