|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #64313 DateTime & DateTimeZone constructs should emit DateTimeException
Submitted: 2013-02-27 18:46 UTC Modified: 2017-01-16 14:43 UTC
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: mattsch at gmail dot com Assigned:
Status: Closed Package: Date/time related
PHP Version: 5.3.22 OS:
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: mattsch at gmail dot com
New email:
PHP Version: OS:


 [2013-02-27 18:46 UTC] mattsch at gmail dot com
DateTime and DateTimeZone constructs currently emit Exception but they should really emit an exception related to their respective classes.  The reason for this is the code can run in multiple environments (ui, phpunit, etc).  If I want the exception to bubble up to the base exception in my application environment, I want to catch it and rethrow it with an exception that ultimately extends my app base exception.  As a result, I must catch the base php Exception class and rethrow it with the wrapper exception which extends my base app exception.  The problem comes when I try to run testcases on the class in the phpunit environment.  Since phpunit emits exceptions, catching Exception will also catch phpunit environment exceptions which is not what I want.  As a result, I must check the instance of the exception and allow phpunit exceptions to go through unchanged.  If the DateTime and DateTimeZone classes did not throw Exception, then this would not be a problem.  In fact, I don't think any php command should actually throw the main php Exception and should always throw an exception that is extended from Exception to avoid problems like this.

Test script:
class DateTimeWrapper
	private $dateTime;

	public function __construct($time = 'now', DateTimeZone $timezone = null, $format = null)
		$this->setDateTime($time, $timezone, $format);
	public function setDateTime($time = 'now', DateTimeZone $timezone = null, $format = null)
		try {
			$this->dateTime = new DateTime($time, $timezone);
		catch (Exception $e) {
				PHP DateTime really shouldn't throw the catch all Exception so the workaround is
				to keep this from catching phpunit exceptions as well so do instance checks on it.
			// @codeCoverageIgnoreStart
			if ($e instanceof PHPUnit_Framework_Error
				|| $e instanceof PHPUnit_Framework_Exception) {
				throw $e;
			// @codeCoverageIgnoreEnd
			throw new DateTimeWrapperException($e->getMessage(), $e->getCode(), $e);

Expected result:
php should not throw Exception directly but rather an exception that extends Exception.

Actual result:
php throws Exception in places like DateTime and DateTimeZone when it should really throw an exception like DateTimeException instead which would extend Exception.


fix_suggestion_64313 (last revision 2013-03-01 21:16 UTC by jellofishi at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2013-02-27 18:47 UTC] mattsch at gmail dot com
Forget the $format part of the test script.  I changed the class slightly to show a simplified form of the problem.
 [2015-08-18 13:28 UTC]
JFTR: PHP throws a TypeError instead of Exception, if the second
argument isn't a DateTime, see <>.
 [2017-01-16 06:53 UTC]
Thank you for taking the time to consider this and also add a patch.

Sadly this has not received the attention it should have received and now the patch targets an old and outdated version of PHP. Would you mind addapting the patch so that it works with the current versions of PHP? And perhaps open a PR against That would make integration of the patch even easier.

 [2017-01-16 14:43 UTC] mattsch at gmail dot com
-Status: Open +Status: Closed
 [2017-01-16 14:43 UTC] mattsch at gmail dot com
I find the new behavior in php >= 7 acceptable where it throws a TypeError instead.  That's probably more appropriate anyway.  I'm going to close this feature request.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Mar 03 10:01:29 2024 UTC