|
|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
[2013-06-08 06:45 UTC] 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"; } PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2024 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 23 21:01:28 2024 UTC |
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.