Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:55869
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.184 cause and error)
Message-ID: <4E9E79DA.6070404@lsces.co.uk>
Date: Wed, 19 Oct 2011 08:18:50 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110907 Firefox/6.0.2 SeaMonkey/2.3.3
MIME-Version: 1.0
To: PHP Internals List <internals@lists.php.net>
References: <20111018214522.GA10462@panix.com>
In-Reply-To: <20111018214522.GA10462@panix.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] DateTime and Daylight Saving Time Transitions
From: lester@lsces.co.uk (Lester Caine)

Daniel Convissor wrote:
> PHP's DateTime class has unexpected outcomes when dealing with the
> transitions between Daylight Saving Time and Standard Time.
>
> Properly defining, documenting and unit testing DateTime's behaviors is
> important for PHP's future. This document seeks agreement on what the
> expected behaviors should be.
>
> Please take a moment to review the RFC and post any questions or
> concerns here.
>
> https://wiki.php.net/rfc/datetime_and_daylight_saving_time

I feel that it is worth pointing out that handling the transitions is more a 
matter of making the right design choices in the underlying design. Having had 
to manage this for many years in timetabling systems for railways, I've come to 
one simple conclusion, and that is that the internal system always works with 
UTC times. All of the calculations and 'timing diagrams' therefore have unique 
and sequential times.

The discussion then comes back to mapping UTC times to and from the local times 
which is a lot easier to manage?

Rather than complex maths to try and correct the 'Type3' times, if they are 
automatically stored internally as a UTC time, and only the displayed 
information is varied, then the maths problem goes away? This will handle any 
complex daylight saving offsets cleanly? Having the same mechanism for all time 
values would also remove the need to have to handle that processing in the 
application?

Moving to multi-timezone applications, by working purely in UTC in the stored 
data, all that the application requires is to know the timezone of the client ( 
long time grip - this needs to be provided via the browser! ) or the timezone of 
the location. Single timezone only really exist if there is no daylight saving 
in the area being served, and then it simply does not matter if the system is 
using UTC on the server or the local time.

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/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