Bug #67881 [Com]: DateTimeZone and DateTime constructors log php warnings when they shouldn't.
Edit report at https://bugs.php.net/bug.php?id=67881&edit=1
ID: 67881
Comment by: evert at rooftopsolutions dot nl
Reported by: evert at rooftopsolutions dot nl
Summary: DateTimeZone and DateTime constructors log php
warnings when they shouldn't.
Status: Open
Type: Bug
Package: Date/time related
Operating System: Any
PHP Version: 5.5.15
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2014-08-21 17:56:15] 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:54:42] 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 14:01:53] 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
)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=67881&edit=1
Thread (8 messages)