Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42120
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 213.123.26.183 cause and error)
Message-ID: <493A08F3.6090500@lsces.co.uk>
Date: Sat, 06 Dec 2008 05:09:07 +0000
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.8.1.18) Gecko/20081112 SeaMonkey/1.1.13
MIME-Version: 1.0
To: PHP Developers Mailing List <internals@lists.php.net>
References: <4938C8FB.6010509@lsces.co.uk> <alpine.DEB.2.00.0812051018150.4897@kossu.ez.no>
In-Reply-To: <alpine.DEB.2.00.0812051018150.4897@kossu.ez.no>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Upgrading to internal DateTime
From: lester@lsces.co.uk (Lester Caine)

Derick Rethans wrote:
>> ( 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.

OK - I think I understand what is 'missing' now!

The only thing ever stored in the database *IS* Unix timestamps. Doing 
anything other than that is unmanageable, yet some frameworks use 
'server based' times in their systems, simply because they do not bother 
with daylight saving and only 'serve' one timezone!

The second you have to manage 'real' time across timezones then daylight 
saving becomes essential, BUT only on the display side! Since the 
browser only provides a time offset, this is useless and to be honest 
should simply be ignored ( until it is upgraded to provide the correct 
information  ;) ). So we need a 'display' function that takes a simple 
numeric epoch, and a separate timezone id into which the epoch is to be 
'converted'. My W3C mapping works simply because ADOdb then converts 
that to it's own simple offset abbreviation - in my case GMT or BST. As 
long as DateTime passes the full 64 bit number the date range from 100AD 
is also preserved ( and further back if 2 digit years are disabled ). If 
I want to display the 'real' timezone with this 'time' then I just add 
it in place of ADOdb's 'timezone'. I am tempted to simply adjust the 
ADOdb class to take a timezone in place of the simple GMT switch it 
currently uses.

The return path is just the reverse and simply needs to take the client 
display offset off prior to storage of the UTC epoch. SO we use 
DateTimeZone to get an offset value for the clients timezone and simply 
add or subtract this from a timezone agnostic display on the client end 
when entering new times.

( I've posted this simply as an aid - it may help someone )

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php