Bug #66018 [Ver->Nab]: incorrect years for DateTime objects created with certain bad month names
Edit report at https://bugs.php.net/bug.php?id=66018&edit=1
ID: 66018
Updated by: derick@php.net
Reported by: kaldari at gmail dot com
Summary: incorrect years for DateTime objects created with
certain bad month names
-Status: Verified
+Status: Not a bug
Type: Bug
Package: Date/time related
Operating System: *
PHP Version: 5.5.5
Block user comment: N
Private report: N
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2013-11-02 01:12:34] kaldari at gmail dot com
That all makes sense. I would be fine with you closing this as invalid.
------------------------------------------------------------------------
[2013-11-01 23:52:19] 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-01 22:56:39] 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)
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=66018&edit=1
Thread (4 messages)