php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #67675 DateTimeZone->getTransitions()->ts returns invalid value
Submitted: 2014-07-24 12:10 UTC Modified: 2021-04-05 15:52 UTC
From: greenrover33 at gmail dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.6Git-2014-07-29 (Git) OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: greenrover33 at gmail dot com
New email:
PHP Version: OS:

 

 [2014-07-24 12:10 UTC] greenrover33 at gmail dot com 
Description:
------------
This ts is empty. Because its a to high/low number.
[ts] => -9223372036854775808 === empty($ts->ts)
[ts] => -9223372036854775808 === !isset($ts->ts)

Test script:
---------------
<?PHP
$tz = new DateTimeZone('Europe/Berlin');

foreach ($tz->getTransitions() as $ts) {
    if (empty($ts->ts)) {
        echo "HRERE is the bug\n";
        print_r($ts);  

        echo "\n\nfull log:\n";
        print_r($tz->getTransitions());
        die();
    }
}

echo "The bug was fixed";
die();


Expected result:
----------------
First row is:
Array
(
    [ts] => -9223372036854775808
    [time] => -292277022657-01-27T08:29:52+0000
    [offset] => 7200
    [isdst] => 1
    [abbr] => CEST
)

Actual result:
--------------
First row should be:

Array
(
    [ts] => -1693706400
    [time] => 1916-04-30T22:00:00+0000
    [offset] => 7200
    [isdst] => 1
    [abbr] => CEST
)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-07-29 11:36 UTC] greenrover33 at gmail dot com
-PHP Version: 5.5.15 +PHP Version: 5.6Git-2014-07-29 (Git)
 [2014-07-29 11:36 UTC] greenrover33 at gmail dot com 
Tested it with:  5.6Git-2014-07-29 (Git)
 [2014-07-29 14:29 UTC] derick@php.net
-Assigned To: +Assigned To: derick
 [2014-07-29 14:29 UTC] derick@php.net 
You're right that it shouldn't be MIN_LONG, but the first entries should be:

Europe/Berlin  Fri Mar 31 23:06:31 1893 UT = Fri Mar 31 23:59:59 1893 LMT isdst=0 gmtoff=3208
Europe/Berlin  Fri Mar 31 23:06:32 1893 UT = Sat Apr  1 00:06:32 1893 CET isdst=0 gmtoff=3600
Europe/Berlin  Sun Apr 30 21:59:59 1916 UT = Sun Apr 30 22:59:59 1916 CET isdst=0 gmtoff=3600
Europe/Berlin  Sun Apr 30 22:00:00 1916 UT = Mon May  1 00:00:00 1916 CEST isdst=1 gmtoff=7200
Europe/Berlin  Sat Sep 30 22:59:59 1916 UT = Sun Oct  1 00:59:59 1916 CEST isdst=1 gmtoff=7200
Europe/Berlin  Sat Sep 30 23:00:00 1916 UT = Sun Oct  1 00:00:00 1916 CET isdst=0 gmtoff=3600
 [2017-10-24 08:13 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: derick +Assigned To:
 [2021-01-25 13:36 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2021-01-25 13:36 UTC] cmb@php.net 
> You're right that it shouldn't be MIN_LONG, […]
 [2021-04-05 15:52 UTC] derick@php.net
-Status: Verified +Status: Not a bug
 [2021-04-05 15:52 UTC] derick@php.net 
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

This is the right result.

$ zdump -v Europe/Berlin -c 1000,1900
Europe/Berlin  -9223372036854775808 = NULL
Europe/Berlin  -9223372036854689408 = NULL
Europe/Berlin  Fri Mar 31 23:06:31 1893 UT = Fri Mar 31 23:59:59 1893 LMT isdst=0 gmtoff=3208
Europe/Berlin  Fri Mar 31 23:06:32 1893 UT = Sat Apr  1 00:06:32 1893 CET isdst=0 gmtoff=3600
Europe/Berlin  9223372036854689407 = NULL
Europe/Berlin  9223372036854775807 = NULL

Before 1893 (until the beginning of time) the UTC offset was indeed 3208s.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Fri May 09 23:01:31 2025 UTC