Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56933
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4EE91FDE.1060005@sugarcrm.com>
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>
Date: Thu, 15 Dec 2011 11:17:25 +0100
Message-ID: <CAEZPtU4dHVS7igfM9vg1V42Ti9Ne3_0MfYPdz-oqX2XN4p2=_A@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Will Fitch <will.fitch@gmail.com>, Oleg Oshmyan <chortos@inbox.lv>, 
	Derick Rethans <derick@php.net>, PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Local time zone
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Dec 14, 2011 at 11:14 PM, Stas Malyshev <smalyshev@sugarcrm.com> wr=
ote:
> Hi!
>
>
>> I believe he's referring to sys/time.h, but this introduces
>> portability issues. =A0If 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 allo=
ws
> to do it, I don't think it would be too bad to have it. Even Unix-only mi=
ght
> be (again, if enough people need it) fine, if we could use the data prope=
rly
> 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,
--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org