Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56954
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
Message-ID: <4EEFD86D.8090905@gmail.com>
Date: Tue, 20 Dec 2011 11:35:57 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: Stas Malyshev <smalyshev@sugarcrm.com>, 
 Will Fitch <will.fitch@gmail.com>,
 Oleg Oshmyan <chortos@inbox.lv>, Derick Rethans <derick@php.net>, 
 PHP Developers Mailing List <internals@lists.php.net>
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> <alpine.DEB.2.02.1112141019110.27751@whisky.home.derickrethans.nl> <A04EB7D2-BEF6-4843-914A-D3F84EE4F8CF@inbox.lv> <4EE91556.3040909@sugarcrm.com> <FF91DB7C-BEC3-4046-B19C-2EF0B49B3A07@gmail.com> <4EE91FDE.1060005@sugarcrm.com> <CAEZPtU4dHVS7igfM9vg1V42Ti9Ne3_0MfYPdz-oqX2XN4p2=_A@mail.gmail.com>
In-Reply-To: <CAEZPtU4dHVS7igfM9vg1V42Ti9Ne3_0MfYPdz-oqX2XN4p2=_A@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Local time zone
From: davidkmuir@gmail.com (David Muir)

On 15/12/11 21:17, Pierre Joye wrote:
> On Wed, Dec 14, 2011 at 11:14 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
>> Hi!
>>
>>
>>> I believe he's referring to sys/time.h, but this introduces
>>> portability issues.  If it were just unix, that would be one thing.
>>> But maintaining this and a Windows alternative, and I have no idea
>>> what that is, is not worth it IMO.
>>
>> Yes, portability is questionable. Though if we had a good patch that allows
>> to do it, I don't think it would be too bad to have it. Even Unix-only might
>> be (again, if enough people need it) fine, if we could use the data properly
>> in timelib functions.
> By portability it is not (only) about APIs, APIs wrapping is easy
> these days, even on Windows.
>
> But the actual problem is to get a consistent and constantly updated
> set of data, reliable data. Data that applications can use blindly on
> any platforms without having to worry about bad information, as long
> as they use the latest PHP or timezone release (via PECL for example).
>
> And that, as stated earlier, is why we should not provide any
> alternative as any other solutions failed so far. It is also even less
> important as Oleg's target is the developer environment. If a
> developer cannot set his TZ correctly in a php.ini or in his
> application on his development box, then something is wrong there, but
> not in php :)
>
> For production server, I would never ever suggest to use the system's
> TZ, no matter the OS/distros/etc..
>
> Cheers,

Isn't this whole thread about client-side apps, not server-side. For
client-side stuff it doesn't make sense to use anything but the system
tz. Should we be expecting users to have to edit php.ini files every
time they hop on a plane or drive across a tz border? And what about
non-developers?

Keeping the tz database up to date is a very annoying issue. System tz
data is typically more up-to-date as it's pushed to the user, while with
php, you need to have admin rights to install an updated tz database, or
hope that the packager for your distro (or your web-host) does it for
you. As far as I can tell, most hosts do not update timezone data from
PECL. I just checked one host that is still on 5.2:

date/time support     enabled
"Olson" Timezone Database Version     2010.9
Timezone Database     internal
Default timezone     UTC

Sigh...

Ubuntu however reports 0.system as the tz version. Does that mean that
PHP there is using the system's tz database instead?

Cheers
David