Everything

php

[RFC] DateTime and Daylight Saving Time Transitions

php.internals

Daniel Convissor

14 years ago

Hello!

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

Thanks,

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Lester Caine

14 years ago

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

Daniel Convissor

14 years ago

On Wed, Oct 19, 2011 at 08:18:50AM +0100, Lester Caine wrote:

> 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.

That is how PHP's DateTime works.

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Daniel Convissor

14 years ago

Hi:

> https://wiki.php.net/rfc/datetime_and_daylight_saving_time

I will move this to voting phase tomorrow unless I hear objections.

Thanks,

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

Stas Malyshev

14 years ago

Hi!

>> https://wiki.php.net/rfc/datetime_and_daylight_saving_time
>
> I will move this to voting phase tomorrow unless I hear objections.

Not an objection but more a side question - is this related to fixing
TLA timezones in general? Right now they fail in a multitude of
scenarios which have nothing to do with transitions, such as:

$t   = new DateTime('2010-07-06 18:38:28 EDT');
$ts = $t->format('U');
$t->setTimestamp($ts);
var_dump($t);

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

Daniel Convissor

14 years ago

Hi Stas:

On Mon, Oct 24, 2011 at 09:57:51AM -0700, Stas Malyshev wrote:

>
> Not an objection but more a side question - is this related to
> fixing TLA timezones in general? Right now they fail in a multitude
> of scenarios which have nothing to do with transitions, such as:
>
> $t   = new DateTime('2010-07-06 18:38:28 EDT');
> $ts = $t->format('U');
> $t->setTimestamp($ts);
> var_dump($t);

Fun!  I have a feeling that has the same underlying issue as
https://bugs.php.net/bug.php?id=55253 which needs to be fixed as part of
implementing the RFC.

Thanks,

--Dan

--
T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409