Edit report at https://bugs.php.net/bug.php?id=40743&edit=1
ID: 40743
Comment by: kavi at postpro dot net
Reported by: ddb at bitxtender dot de
Summary: DateTime ignores the TimeZone object passed to the
constructor
Status: Re-Opened
Type: Feature/Change Request
Package: Date/time related
Operating System: Win XP
PHP Version: 5.2.1
Assigned To: derick
Block user comment: N
Private report: N
New Comment:
Yes, it's a feature request for PHP to not soldier on without objection in a
situation that is quite likely to be involved in a logic error. This should be
an E_WARNING at minimum.
Previous Comments:
------------------------------------------------------------------------
[2013-01-06 16:13:39] [email protected]
It's still not a bug, so changing it to a feature request. The "@" acts as a
timezone specifier and if there is one of those in the string to parse, then a
passed in timezone doesn't override this. This works the same as:
$a = new DateTime("2013-01-06 16:12 CEST", new DateTimeZone("Asia/Tokyo"));
var_dump( $a );
which shows:
class DateTime#1 (3) {
public $date =>
string(19) "2013-01-06 16:12:00"
public $timezone_type =>
int(2)
public $timezone =>
string(4) "CEST"
}
------------------------------------------------------------------------
[2012-05-17 19:29:38] [email protected]
Still present in master.
<?php
$dt = new DateTime('@' . time(), new DateTimeZone('Europe/Berlin'));
var_dump($dt, $dt->getTimeZone()->getName());
object(DateTime)#1 (3) {
["date"]=>
string(19) "2012-05-17 19:29:15"
["timezone_type"]=>
int(1)
["timezone"]=>
string(6) "+00:00"
}
string(6) "+00:00"
------------------------------------------------------------------------
[2012-02-09 02:28:58] kavi at postpro dot net
This bug is NOT fixed on 5.3.3 or trunk.
$ php
<?php
$a = new DateTime('Monday, 15-Aug-05 15:52:01 PDT', new
DateTimeZone('America/New_York'));
print_r($a);
DateTime Object
(
[date] => 2005-08-15 15:52:01
[timezone_type] => 2
[timezone] => PDT
)
------------------------------------------------------------------------
[2008-01-17 18:50:12] [email protected]
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.
------------------------------------------------------------------------
[2007-04-19 20:53:33] artur at jedlinski dot pl
It is ignoring the #2 parameter when you put the timezone info inside the #1.
It's *absolutely* unacceptable.
// Europe/Warsaw = GMT +0200
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc, new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."<br />";
// RESULT: 12:50:00 (expected: 14:50:00)
$dateTime->setTimeZone(new DateTimeZone('Europe/Warsaw'));
echo $dateTime->format('H:i:s')."<br />";
// RESULT: 14:50:00 (correct)
IMHO the most intuitive way is to create the date based on the #1, but displays
it using #2.
It's not only strange it ignores #2, but in fact it's strange that the internal
DateTime pointer is set to timezone provided in #1 at all. If the
date_default_timezone_set() was set to some TZ, it should create dates within
this timezone if one doesn't state otherwise (using #2). Of course the timezone
info from #1 should be used, but only to calculate the actual timestamp.
date_default_timezone_set('Europe/Warsaw');
$dateSrc = '2007-04-19 12:50:00 GMT';
$dateTime = new DateTime($dateSrc);
echo $dateTime->format('H:i:s')."<br />";
// RESULT: 12:50:00 (expected: 14:50:00)
Currently, it's pretty complicated to translate dates from one timezone to
another - you have to use DateTime::setTimeZone(), when one line should do the
thing:
$dateTime = new DateTime($dateWithSrcTimeZone, $timeZoneToDisplay);
(or even without $timeZoneToDisplay if you want to use your current TZ).
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=40743
--
Edit this bug report at https://bugs.php.net/bug.php?id=40743&edit=1
