Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42112
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.94.239.7 as permitted sender)
Date: Fri, 5 Dec 2008 10:22:16 +0100 (CET)
To: Lester Caine <lester@lsces.co.uk>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <4938C8FB.6010509@lsces.co.uk>
Message-ID: <alpine.DEB.2.00.0812051018150.4897@kossu.ez.no>
References: <4938C8FB.6010509@lsces.co.uk>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] Upgrading to internal DateTime
From: derick@php.net (Derick Rethans)

On Fri, 5 Dec 2008, Lester Caine wrote:

> First question.
> Why are there two different formats for dates with date creation using one
> format and everything else using strftime formatting?

Don't understand what you mean by this.

> ( Slipping a date through DateTime and returning it DATE_W3C seems to be
> adding the correct daylight saving details so far and allowing ADOdb date to
> work )

This is not the correct thing to do, as you will lose timezone 
information. The W3C format only stores UTC offsets (in the form of 
+00:00). However, that same UTC offset can be used in different areas 
with different DST changes. Best thing is to store in Unix timestamps.

> Second question.
> What is the current situation on translating dates? I've tried several ways of
> using setlocale, but at present I've not been able to get anything other than
> English out of the code.

setlocale() is the only real solution right now. What most likely is 
your problem is that you don't have the locales for the other languages 
installed.

> Third question
> In order to get things working I've ended up with date_default_timezone_set()
> and haven't needed to use DateTimeZone at all ( other than to get a list for
> the user to select from ). Internally we are working UTC normalized, and then
> displaying with the user offset if they select 'local'. IS the correct thing
> to be setting the default for each user? I suspect yes since previous code has
> always had to fight the server time setting changing things.

Yes, I would do so as well. Especially because all date/time functions 
use this timezone. DateTime objects however can have information 
embedded to override this default timezone though. DateTimeZone is only 
really useful to get information from timezones, to do DST calculations 
etc. 

regards,
Derick

-- 
HEAD before 5_3!: http://tinyurl.com/6d2esb
http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org