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