Edit report at https://bugs.php.net/bug.php?id=64992&edit=1
ID: 64992
Updated by: derick@php.net
Reported by: eclipsechasers2 at yahoo dot com
Summary: dst not handled past 2038
-Status: Re-Opened
+Status: Closed
Type: Bug
Package: Date/time related
Operating System: Windows and Linux
PHP Version: 5.4.16
-Assigned To:
+Assigned To: derick
Block user comment: N
Private report: N
New Comment:
The fix for this bug has been committed.
If you are still experiencing this bug, try to check out latest source from https://github.com/php/php-src and re-test.
Thank you for the report, and for helping us make PHP better.
Fixed for PHP 8.1.
Previous Comments:
------------------------------------------------------------------------
[2020-08-18 14:21:35] sander at recras dot nl
Just ran into this issue. For API testing, we often use dates far in the future. Apparently,
2038-08-18 was too far for a new test. A time that should be represented as +02:00 was represented
as +01:00.
This may not be a big issue yet, but given how long this bug has been open (42842 was opened nearly
13 years ago), let's hope it won't take another 13 years because then it will get
annoying.
------------------------------------------------------------------------
[2020-06-09 14:28:03] tyler at mitton dot ca
Derick, if this cannot be fixed in a way that makes it go on indefinitely, then I would suggest that
a *more* appropriate end time would be anything after 2038... I'll throw out 2100 as it seems
to make a lot more sense than 2038 which is not that far away.
I cannot believe this is still an issue in 2020.
------------------------------------------------------------------------
[2019-05-28 09:44:36] derick@php.net
What would be an appropriate end time, considering that the more data we add, the larger the PHP
binaries will get.
------------------------------------------------------------------------
[2019-05-24 20:08:09] zane at collected dot team
I agree with mlambley, this shouldn't be an issue of political whims or safety of assumptions,
this should be about consistency. 2038 is only 19 years away, it is not unreasonable to get
information about dates and times that are that close. PHP is the backbone for a large percentage of
the internet, this is a major issue and needs to be fixed.
I'm working on a scheduling system that uses UTC timestamps and DateTime to create dates,
schedules, events, etc. But since PHP won't calculate DST past 2037 my site is literally broken
for my users. There are definitely workarounds for this, but that it literally the reason DateTime
exists...
------------------------------------------------------------------------
[2018-06-26 04:29:18] mlambley at gmail dot com
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.
------------------------------------------------------------------------
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