Edit report at https://bugs.php.net/bug.php?id=64992&edit=1
ID: 64992
Comment by: mlambley at gmail dot com
Reported by: eclipsechasers2 at yahoo dot com
Summary: dst not handled past 2038
Status: Re-Opened
Type: Bug
Package: Date/time related
Operating System: Windows and Linux
PHP Version: 5.4.16
Block user comment: N
Private report: N
New Comment:
For me, the question isn't whether or not it "safe to assume so far in advance". The
fact is that my system is broken right now because PHP's behaviour is inconsistent.
My system receives a DateTime object with time zone, converts using ->format('c'), and
writes to the database. Beyond 2037, it records the date one day behind. Because instead of writing
midnight+10:00 it writes midnight+11:00 which is 11pm the previous night.
My workaround is to create another DateTime object with a fixed pre-2037 date, compare the time
zones, and adjust the date accordingly. It should not be necessary, because PHP's behaviour
should be consistent.
Thank you for your time and attention to this ticket.
Previous Comments:
------------------------------------------------------------------------
[2018-06-26 04:03:33] requinix@php.net
Related To: Bug #76530
------------------------------------------------------------------------
[2018-04-26 11:03:37] pmmaga@php.net
I agree with the reporter and Paul that currently, there is no good reason for PHP to keep this
behavior. It is an arbitrary restriction.
------------------------------------------------------------------------
[2018-04-24 09:53:34] paul dot crovella at gmail dot com
> As DST can change at any time due to politcal reasons it is not safe to calculate DST for
> multiple years in advance. This is not a limitation of PHP or the used timezoneDB but of the fact
> that DST is handled on a political level.> This is therefore not a bug in PHP.
Whatever your thoughts are on the safety of this, there's nothing that makes a 2038 cutoff
special other than the previous limitation of the timezone database. Since that limitation
apparently no longer applies keeping 2038 as the cutoff is entirely arbitrary.
PHP should make available what is reasonable technically and leave the decision to the developer.
------------------------------------------------------------------------
[2017-01-14 16:30:08] eclipsechasers2 at yahoo dot com
Nonsense! Given the correct information, I can decide on my own whether it is advisable to use it.
Given incorrect information, I can't do anything. PHP WILL have this problem at the epoch
change (ALL current times will be unreliable); it probably has others. You can go into panic mode
and try to fix them all at once as the deadline looms. Or you can handle them in a sane manner,
fixing them as they are identified well in advance of any deadline.
------------------------------------------------------------------------
[2017-01-13 16:04:16] heiglandreas@php.net
See previous comment
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=64992
--
Edit this bug report at https://bugs.php.net/bug.php?id=64992&edit=1