php.net |  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
 [2019-09-06 08:55 UTC] slawek1211 at gmail dot com
Description:
------------
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...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-09-07 14:50 UTC] girgias@php.net
-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] girgias@php.net
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);
$time_1->setTimezone(($tz1));
var_dump($time_1->format("Y-m-d H:i:s"));

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

Output Never Notice or Warnings here.
 [2022-05-13 16:00 UTC] derick@php.net
-Status: Assigned +Status: Not a bug
 [2022-05-13 16:00 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 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: Sat Dec 07 18:02:35 2024 UTC