|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #78504 Add warnings to DateTime object with incompatible timezone info
Submitted: 2019-09-06 08:55 UTC Modified: 2022-05-13 16:00 UTC
From: slawek1211 at gmail dot com Assigned: derick (profile)
Status: Not a bug Package: Date/time related
PHP Version: Next major version OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
49 + 1 = ?
Subscribe to this entry?

 [2019-09-06 08:55 UTC] slawek1211 at gmail dot com
Hi Guys, i think there's a small issue with how DateTime object works and it can be made much better with just a very small change. So now when you're using timestamp in constructor or in DateTime::CreateFromFormat then php silently ommits specified timezone. Same thing happens when you include timezone in the time itself, and also specify it - then timezone contained in time string has preference.

This is documented, but very counter-intuitive. So in case where the object gets created with different timezone than specified in $timezone parameter it would be great to include a warning.

Test script:
// Example 1
$tz = new DateTimeZone('America/New_York');
$time_o = new DateTime('@'.time(), $tz);
var_dump($time_o->format("Y-m-d H:i:s"));
echo "<br>";

// Example 2
$time_o = DateTime::CreateFromFormat("U", time(), $tz);
var_dump($time_o->format("Y-m-d H:i:s"));

Expected result:
Add 2 warnings, depending on case. 

1. Warning: DateTime object created from timestamp, timezone forced to UTC (ignoring America/New_York) in line 2

2. Warning: CreateFromFormat has timezone specified both in $time and in $timezone, ignoring $timezone in line 1

Actual result:
PHP is silently ignoring optional function parameter specified by user. Which is counter intuitive, because if someone specifies time and timezone he's probably counting on that time to be presented in timezone given, despite the format.

Other action which would make it better is to always honor $timezone first. Because many people find this confusing that the parameter gets ignored in DateTime documentation. But this could break existing code and probably is much harder to implement so just a warning would be great...


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-09-07 14:50 UTC]
-Summary: DateTime can quietly produce unexpected results +Summary: Add warnings to DateTime object with incompatible timezone info -Operating System: All OS'es (documented) +Operating System: -PHP Version: 7.1.32 +PHP Version: Next major version -Assigned To: +Assigned To: derick
 [2019-09-07 14:50 UTC]
As this adds warnings this would need to be for PHP 8 as it is a BC break, not sure this needs an RFC so assign to derick which maintains the datetime extension.
 [2019-12-14 16:02 UTC] antonino dot spampinato86 at gmail dot com
From php 5.2.1 it is possible to use the time zone, not to create warnings generated because the utility of this function setTimeZome is modified specifically for DateTimeZone

$tz1 = new DateTimeZone('UTC');
$timestamp = time();
$time_1 = new DateTime('@'.$timestamp);
var_dump($time_1->format("Y-m-d H:i:s"));

$tz2 = new DateTimeZone('America/New_York');
$time_2 = new DateTime('@'.$timestamp);
var_dump($time_2->format("Y-m-d H:i:s"));

Output Never Notice or Warnings here.
 [2022-05-13 16:00 UTC]
-Status: Assigned +Status: Not a bug
 [2022-05-13 16:00 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

This is both documented and expected, and adding warnings for potential user input is not a great idea. I'm going to mark this as "expected", and won't add these warnings.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jun 18 02:01:30 2024 UTC