Edit report at https://bugs.php.net/bug.php?id=64992&edit=1
ID: 64992
Comment by: eclipsechasers2 at yahoo dot com
Reported by: eclipsechasers2 at yahoo dot com
Summary: dst not handled past 2038
Status: Not a bug
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:
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.
Previous Comments:
------------------------------------------------------------------------
[2017-01-13 16:04:16] heiglandreas@php.net
See previous comment
------------------------------------------------------------------------
[2017-01-13 16:03:54] heiglandreas@php.net
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.
For more details see https://andreas.heigl.org/2016/12/22/why-not-to-convert-a-datetime-to-timestamp/
------------------------------------------------------------------------
[2013-06-12 19:39:55] aharvey@php.net
Related To: Bug #42842
------------------------------------------------------------------------
[2013-06-08 06:45:14] eclipsechasers2 at yahoo dot com
Description:
------------
This could be considered a duplicate of bug 42842. That bug was marked suspended in 2007. The
reasons for its suspension are no longer valid. I updated that ticket, but, after a week with no
feedback whatsoever, am opening a new ticket in the hope that it will get a reply. PHP does not
handle dst transitions from the year 2038 on. This happens on Windows and Linux, on 32- and 64-bit
systems. It happens with all releases, including the most current (5.4.16), and even when PECL is
used to install timezonedb. The reason the ticket was suspended was "the timezone database
simply doesn't have the resolution to store anything outside of the signed integer range for
now." That is no longer true, and a 5-year delay seems time enough to implement it in PHP. The
Unix zdump command handles the transition on 64-bit Linux systems (including the latest Ubuntu).
Perl handles the transition on Windows and Linux, even on 32-bit systems.
Test script:
---------------
<?php
$firstyear = 2035;
$lastyear = 2040;
$tz = 'America/Los_Angeles';
date_default_timezone_set('America/Los_Angeles');
$dt = new DateTime((string) ($firstyear - 1) . "-07-02");
$di = new DateInterval('P6M');
for ($i = 0; $i < ($lastyear - $firstyear) * 2; $i++) {
$dt->add($di);
$gmto = $dt->getOffset();
echo "Time Zone offset for $tz for " , $dt->format('Y-m-d') , " is
$gmto\n";
}
?>
Expected result:
----------------
Time Zone offset for America/Los_Angeles for 2035-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2035-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2036-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2036-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2037-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2037-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2038-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2038-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2039-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2039-07-02 is -25200
Actual result:
--------------
Time Zone offset for America/Los_Angeles for 2035-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2035-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2036-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2036-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2037-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2037-07-02 is -25200
Time Zone offset for America/Los_Angeles for 2038-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2038-07-02 is -28800
Time Zone offset for America/Los_Angeles for 2039-01-02 is -28800
Time Zone offset for America/Los_Angeles for 2039-07-02 is -28800
The lines for 2038-07-2 and 2039-07-02 are wrong; they should show -25200.
A zdump command which shows the correct values is:
zdump -v -c 2035,2039 America/Los_Angeles
Here is an equivalent Perl script which displays all the lines correctly:
#!/usr/bin/perl -w
use strict;
use DateTime;
my $firstyear = 2035;
my $lastyear = 2040;
my $tz = 'America/Los_Angeles';
my $dt = DateTime->new(year=>($firstyear - 1), month=>7, day=>2, time_zone=>$tz);
for (my $i = 0; $i < ($lastyear - $firstyear) * 2; $i++) {
$dt->add(months=>6);
my $gmto = $dt->offset();
printf "Time Zone offset for $tz for " . $dt->ymd('-') . " is
$gmto\n";
}
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=64992&edit=1