php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #78203 date_create function behaves weird if the argument is "a string"
Submitted: 2019-06-25 07:02 UTC Modified: 2019-09-02 21:15 UTC
From: masergiu at gmail dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: Irrelevant OS: any
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: masergiu at gmail dot com
New email:
PHP Version: OS:

 

 [2019-06-25 07:02 UTC] masergiu at gmail dot com
Description:
------------
DateTime::__construct and its alias, date_create function, are returning weird results for the following cases:
1. date_create('test') => returns false, which is expected according to documentation;
2. date_create('a test') => retuns the DateTime object constructed as "new DateTime('now')", which is not expected.

Same is valid for new DateTime() process:
1. new DateTime('test') => throws Exception, which is expected according to documentation;
2. new DateTime('a test') = retuns the DateTime object constructed as "new DateTime('now')", which is not expected.

Test script:
---------------
php -r "var_dump(date_create('test')); // EXPECTED result"

php -r "var_dump(date_create('a test')); // UNEXPECTED result"

Expected result:
----------------
For the script below it should return FALSE also:
php -r "var_dump(date_create('a test')); // UNEXPECTED result"

Actual result:
--------------
For the script below it returns DateTime object constructed as "new DateTime('now')":
php -r "var_dump(date_create('a test')); // UNEXPECTED result"

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-09-02 11:18 UTC] lol at reddit dot com
This is lolphp.
 [2019-09-02 21:15 UTC] requinix@php.net
-Status: Open +Status: Not a bug
 [2019-09-02 21:15 UTC] requinix@php.net
Expected:
"test" is parsed to be a timezone (1-6 letters), but there is no such timezone so that's an error.

Unexpected:
"a" is parsed to be a timezone as well, and it exists as the military-style timezone UTC+1.
https://en.wikipedia.org/wiki/List_of_military_time_zones

"test" is still parsed as a timezone, but ignored because there already was one specified in the input string; DateTime::getLastErrors() reports "Double timezone specification".
https://3v4l.org/1ViMC


PHP's date string interpretation is optimistic: it assumes the input is a valid date and tries to derive the most reasonable result. If the input isn't valid then parsing may fail, or it may manage to identify something meaningful that it can translate to a date - probably with warnings.
Or as the saying goes: garbage in, garbage out.


It's really easy to say "lolphp" when you don't bother trying to understand, huh?
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Mar 28 23:01:26 2024 UTC