|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2015-06-12 17:44 UTC] cmb@php.net
-Status: Open
+Status: Not a bug
-Assigned To:
+Assigned To: cmb
[2015-06-12 17:44 UTC] cmb@php.net
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 18:00:01 2025 UTC |
Description: ------------ When ever date.timezone INI setting or date_default_timezone_set() is used and a clearly invalid timezone ID is set, DateTime::getLastErrors() has no indication of this. Same if no timezone is set. Test script: --------------- // assume date.timezone currently set to "America/Los_Angeles" for this test date_default_timezone_set( "asdf" ); try { $d = new DateTime(); } catch ( Exception $ex ) { var_dump( DateTime::getLastErrors() ); // never even reached - $d is actually valid and set to "America/Los_Angeles" timezone, and DateTime::getLastErrors() has no errors listed } ini_set( "date.timezone", "asdf" ); try { $d = new DateTime(); } catch ( Exception $ex ) { var_dump( DateTime::getLastErrors() ); // reached, but no errors listed here } Expected result: ---------------- DateTime::getLastErrors() always contains the "The timezone could not be found in the database" error if a bad timezone name is preset, or "You are *required* to use the date.timezone setting or the date_default_timezone_set() function" error if no timezone name is preset. Actual result: -------------- DateTime::getLastErrors() contains no such errors or warnings.