php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #48058 DateTimeZone::getTransitions output different on 64 bit
Submitted: 2009-04-23 08:57 UTC Modified: 2009-05-03 18:45 UTC
From: wharmby at uk dot ibm dot com Assigned: derick (profile)
Status: Closed Package: Date/time related
PHP Version: 5.3, 6CVS (2009-04-30) OS: Linux 64 bit
Private report: No CVE-ID: None
 [2009-04-23 08:57 UTC] wharmby at uk dot ibm dot com
Description:
------------
First entry in array returned by DateTimeZone method getTransitions  (and function timezone_transitions_get()looks bogus on 64 bit systems. I expected same result when running this command on 32 and 64 bit systems.

Problem affects current levels of PHP 5.3 and 6.0 (snapshot timestamp == Wed 22-04-2009 6:30:00 ) only.

Looks like problem caused by use of constant LONG_MIN at around line 3218 in current src of ext/dates/date.c introduced by the following change: 
=====================================================================
Revision 1.43.2.45.2.51.2.28 - (view) (download) (as text) (annotate) - [select for diffs]
Thu Mar 20 19:43:36 2008 UTC (13 months ago) by derick
Branch: PHP_5_3
Changes since 1.43.2.45.2.51.2.27: +57 -24 lines
Diff to previous 1.43.2.45.2.51.2.27 , to branch point 1.43.2.45.2.51

- MFH: Fix the DateTimeZone::getTransitions() algorithm.

======================================================================

Reproduce code:
---------------
<?php

date_default_timezone_set("Europe/London");
$tz = new DateTimeZone("Europe/London");
$tran = $tz->getTransitions();
var_dump( $tran );	

?>

Expected result:
----------------
(as produced by same code running on Linux 32 bits system)

array(243) {
  [0]=>
  array(5) {
    ["ts"]=>
    int(-2147483648)
    ["time"]=>
    string(24) "1901-12-13T20:45:52+0000"
    ["offset"]=>
    int(3600)
    ["isdst"]=>
    bool(true)
    ["abbr"]=>
    string(3) "BST"
  }

Actual result:
--------------
array(243) {
  [0]=>
  array(5) {
    ["ts"]=>
    int(-9223372036854775808) <- == LONG_MIN
    ["time"]=>
    string(30) "-219246529-01-27T08:29:52+0000" <- Bogus looking entry
    ["offset"]=>
    int(3600)
    ["isdst"]=>
    bool(true)
    ["abbr"]=>
    string(3) "BST"
  }


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-04-23 12:35 UTC] derick@php.net
It looks bogus, but it is (sortof) correct. If you go -9223372036854775808 seconds back from 1970-01-01 you end up at a date 219 billion years in the past. Not sure why it formats wrong though.
 [2009-04-24 08:25 UTC] wharmby at uk dot ibm dot com
Hi Derick
   Thanks for atking a look at this. I can see why we end up with the bogus looking entry given that "timestamp_begin" is initialized to LONG_MIN its just that the output is not what I expected to see and I believe it will confuse other users who are perhaps not aware of how the results array is being built. Also given that the remaining entries in the array are the same and we don't produce more transitions (going further into past) on 64 bit would it not make more sense to initialize timestamp_begin to -2147483648 regardless of platform rather than using LON_MIN ? I realize this is a minor issue and there are probably more important issues that need your attention but I do believe the current output will confuse someone some day

Regards
	Andy
 [2009-05-03 18:24 UTC] derick@php.net
This bug has been fixed in CVS.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
 
Thank you for the report, and for helping us make PHP better.

Well, there is a possibility that transitions from before 1901 might be added to the database, so I don't just want to stop that from working.

Also, I fixed the formatting bug for the year value in CVS now.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 09:01:30 2024 UTC