php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66018 incorrect years for DateTime objects created with certain bad month names
Submitted: 2013-11-01 22:56 UTC Modified: 2013-11-02 11:48 UTC
From: kaldari at gmail dot com Assigned:
Status: Not a bug Package: Date/time related
PHP Version: 5.5.5 OS: *
Private report: No CVE-ID: None
 [2013-11-01 22:56 UTC] kaldari at gmail dot com
Description:
------------
DateTime objects created with month names that have any letter appended (other than 'j', 'J', 'I', 'V', or 'X'), and fall between the years 2000 and 2059, default to the current year rather than showing the specified year or throwing an error.

The following strings result in incorrect years:
'9 Junn 2000' -> 9 Jun 2013
'9 XZ 2014' -> 9 Oct 2013
'9 Decemberi 2020' -> 9 Dec 2013

However, both of the following give the correct year:
'9 Decemberi 1999' -> 9 Dec 1999
'9 Decemberi 2060' -> 9 Dec 2060

And all of the following throw an error (which seems sensible):
'9 Decemberj 1999' -> Error
'9 DECJ 2060' -> Error
'9 DECI 2060' -> Error
'9 DECX 2060' -> Error

PHP seems to interpret an appended 'j' or 'J' as a timezone indicator (?!), and 'I', 'V' and 'X' are valid Roman month names, so they trigger a duplicate month error.

The mystery is why PHP doesn't error out in the other cases (and why the years 2000 to 2059 affect the interpretation differently).

This bug blocks the following MediaWiki bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=33579

Test script:
---------------
$tz = new DateTimeZone("Europe/Amsterdam");
$dateObject = new DateTime( '9 junn 2000', $tz );
echo $dateObject->format( 'Y' );
$dateObject = new DateTime( '9 XZ 2014', $tz );
echo $dateObject->format( 'Y' );
$dateObject = new DateTime( '9 decemberi 2020', $tz );
echo $dateObject->format( 'Y' );

Expected result:
----------------
Error or 2000
Error or 2014
Error or 2020

Actual result:
--------------
2013 (current year)
2013 (current year)
2013 (current year)

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-11-01 23:52 UTC] requinix@php.net
-Status: Open +Status: Verified -Operating System: MacOS X +Operating System: *
 [2013-11-01 23:52 UTC] requinix@php.net
I won't close as there may be something worth fixing here, but I will explain what's going on. Consider that:
* single letters except 'j' are for timezones [1]
* what you write as years may be interpreted as times

The overall format for a compound string is date first, time second. When you (accidentally) introduce the timezone it thinks it should expect times next, and will parse something that looks like a valid time as such.

9 Junn 2000      = YYYY-06-09 20:00 UTC-1 = YYYY-06-09 21:00 UTC
9 XZ 2014        = YYYY-10-09 20:14 UTC   = YYYY-10-09 20:14 UTC
9 Decemberi 2020 = YYYY-12-09 20:20 UTC+9 = YYYY-12-09 11:20 UTC

But if the HHMM is invalid then it can only be a year (with the default time of midnight).
9 Decemberi 1999 = 1999-12-09 00:00 UTC+9 = 1999-12-08 15:00 UTC
9 Decemberi 2060 = 2060-12-09 00:00 UTC+9 = 2060-12-08 15:00 UTC

For the others that fail, 'j' is not a valid timezone to specify (it means local time, which is ambiguous) and I/V/X are month names (but you can't specify a month twice).

[1] http://en.wikipedia.org/wiki/List_of_military_time_zones
 [2013-11-02 01:12 UTC] kaldari at gmail dot com
That all makes sense. I would be fine with you closing this as invalid.
 [2013-11-02 11:48 UTC] derick@php.net
-Status: Verified +Status: Not a bug
 [2013-11-02 11:48 UTC] derick@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 04:01:38 2024 UTC