php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73239 DateTime constructor throws exceptions when it should not
Submitted: 2016-10-04 13:23 UTC Modified: 2022-05-20 14:02 UTC
Votes:5
Avg. Score:3.4 ± 1.5
Reproduced:5 of 5 (100.0%)
Same Version:1 (20.0%)
Same OS:2 (40.0%)
From: alec@php.net Assigned:
Status: Closed Package: Date/time related
PHP Version: 7.0.11 OS:
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: alec@php.net
New email:
PHP Version: OS:

 

 [2016-10-04 13:23 UTC] alec@php.net
Description:
------------
When invalid (or empty date.timezone) is configured DateTime constructor will throw an exception instead of a warning.

On PHP7 I can reproduce the issue with invalid date.timezone. It works with empty date.timezone, but it might be environment specific. I have user reports that it throws exception with empty setting. E.g.

PHP Fatal error: Uncaught exception 'Exception' with message 'DateTime::__construct(): It is not safe to rely on the system's timezone settings. You are required to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in ...

This should not happen.The point of falling back to 'UTC' here is exactly to not throw an exception, no?

Test script:
---------------
ini_set('date.timezone', 'dummy');
$dt = new DateTime('now');


Expected result:
----------------
no exception.

Actual result:
--------------
PHP Fatal error:  Uncaught Exception: DateTime::__construct(): Invalid date.timezone value 'dummy', we selected the timezone 'UTC' for now. in ...

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-10-04 15:56 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2016-10-04 15:56 UTC] cmb@php.net
Considering that using date_default_timezone_set() instead of
ini_set() does not cause the DateTime constructor to throw an
exception[1], this inconsistency[2] doesn't make sense.

[1] <https://3v4l.org/NDHgI>
[2] <https://3v4l.org/Rli3e>
 [2016-10-06 16:05 UTC] derick@php.net
IMO, this message is correct. If you add some *broken* data, you very much should get a notice about this. And Exceptions is how a constructor signals this.
 [2016-10-06 18:08 UTC] alec@php.net
No. First, this is a regression, it didn't work this way in older versions. Second, this is not documented. Third, it does not make sense to "select the timezone 'UTC' for now" and then throw an exception.
 [2022-05-20 14:02 UTC] derick@php.net
I've made https://github.com/php/php-src/pull/8594 — it will continue to throw an exception, but the error message is no longer stupid.
 [2022-06-02 08:25 UTC] git@php.net
Automatic comment on behalf of derickr
Revision: https://github.com/php/php-src/commit/b3c6b540a1a8f55de4c624b5f29051d8854fca01
Log: Fixed bug #73239 (DateTime shows strange error message with invalid timezone)
 [2022-06-02 08:25 UTC] git@php.net
-Status: Verified +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 28 10:01:29 2024 UTC