php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #67881 DateTimeZone and DateTime constructors log php warnings when they shouldn't.
Submitted: 2014-08-21 14:01 UTC Modified: 2021-02-16 13:17 UTC
Votes:16
Avg. Score:3.9 ± 1.0
Reproduced:15 of 15 (100.0%)
Same Version:6 (40.0%)
Same OS:10 (66.7%)
From: evert at rooftopsolutions dot nl Assigned: cmb (profile)
Status: Closed Package: Date/time related
PHP Version: 5.5.15 OS: Any
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: evert at rooftopsolutions dot nl
New email:
PHP Version: OS:

 

 [2014-08-21 14:01 UTC] evert at rooftopsolutions dot nl
Description:
------------
When creating new DateTime or DateTimeZone objects, we catch exceptions to ensure ensure that we handle invalid strings.

Despite that, warnings still make their way into the error log.

I don't think we have a way to surpress these errors, as the silence (@) operator also doesn't seem work for this case.

Test script:
---------------
<?php

try {
    $dt = new DateTimeZone('Twilight zone');
} catch (\Exception $e) {
        echo "Caught: " . $e->getMessage() . "\n";
}

print_r(error_get_last());

try {
    $dt = new DateTime('Foo-Bar');
} catch (\Exception $e) {
        echo "Caught: " . $e->getMessage() . "\n";
}

print_r(error_get_last());



Expected result:
----------------
Caught: DateTimeZone::__construct(): Unknown or bad timezone (Twilight zone)
Caught: DateTime::__construct(): Failed to parse time string (Foobar) at position 0 (F): The timezone could not be found in the database


Actual result:
--------------
Caught: DateTimeZone::__construct(): Unknown or bad timezone (Twilight zone)
Array
(
    [type] => 2
    [message] => DateTimeZone::__construct(): Unknown or bad timezone (Twilight zone)
    [file] => /Users/evert/code/phpbug/foo.php
    [line] => 4
)
Caught: DateTime::__construct(): Failed to parse time string (Foobar) at position 0 (F): The timezone could not be found in the database
Array
(
    [type] => 2
    [message] => DateTime::__construct(): Failed to parse time string (Foobar) at position 0 (F): The timezone could not be found in the database
    [file] => /Users/evert/code/phpbug/foo.php
    [line] => 12
)

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-08-21 17:54 UTC] requinix@php.net
-Status: Open +Status: Feedback
 [2014-08-21 17:54 UTC] requinix@php.net
@ and error suppression don't stop the error from happening but rather how it gets reported to an error handler (custom or default). error_get_last() will still tell you about the last error regardless of if/how it was handled.

It sounds like you're saying that code like

  try { new DateTimeZone('Twilight zone'); }
  catch (Exception $e) { /* ignore */ }

generates warnings. I don't see that. Even a custom error handler doesn't get anything - there's just the exception and what's returned by error_get_last().
http://3v4l.org/RmO4T

So I think you're saying that error_get_last() shouldn't be returning anything? Because there wasn't an error raised - just the exception.
 [2014-08-21 17:56 UTC] evert at rooftopsolutions dot nl
-Status: Feedback +Status: Open
 [2014-08-21 17:56 UTC] evert at rooftopsolutions dot nl
Check the error log. There should be something in there.

Also confirmed as a bug by Derick here: https://github.com/fruux/sabre-vobject/pull/116
 [2014-08-21 17:58 UTC] evert at rooftopsolutions dot nl
In a nutshell the main problem is that our users are getting millions of warnings in their error logs, and there's no way we can suppress it.
 [2014-08-21 18:40 UTC] requinix@php.net
Just trying to figure out what the bug is about. I know that I didn't expect error_get_last() to show anything because DateTimeZone is (supposedly) using exceptions instead of errors.
I still can't get it to put anything into the error log though, but I'm sure I just don't have the right combination of settings or something.
 [2014-08-22 10:06 UTC] derick@php.net
It certainly should not be in error_get_last.
 [2016-02-17 10:11 UTC] pascal dot sancho at takoma dot fr
https://3v4l.org/5bN5o
looking at 3v4l.org eval,
reproduced on any PHP version, including PHP7
while HHVM behaves as expected
 [2021-02-16 13:17 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2021-02-16 13:17 UTC] cmb@php.net
This is fixed as of PHP 7.3.0, see <https://3v4l.org/DATvd>.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Dec 22 16:01:31 2024 UTC