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! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
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: Mon Oct 27 04:00:02 2025 UTC