Hi Derick,
I came across with strange DataTime generates legal date from illegal date.
http://3v4l.org/rKFIg
<?php
$date = new DateTime('0000-00-00');
var_dump($date->format('Y-m-d H:i:s'));
$date = new DateTime('0000-01-00');
var_dump($date->format('Y-m-d H:i:s'));
$date = new DateTime('0000-00-01'); // "-0001-12-01 00:00:00" legal date
from illegal date
var_dump($date->format('Y-m-d H:i:s'));
$date = new DateTime('0000-01-01');
var_dump($date->format('Y-m-d H:i:s'));
$date = new DateTime('0001-00-00');
var_dump($date->format('Y-m-d H:i:s')); // "-0002-11-30 00:00:00" legal
date from illegal
$date = new DateTime('0001-01-00');
var_dump($date->format('Y-m-d H:i:s')); // "-0002-12-31 00:00:00" legal
date from illegal
$date = new DateTime('0001-00-01');
var_dump($date->format('Y-m-d H:i:s')); // "-0002-12-01 00:00:00" legal
date from illegal
$date = new DateTime('-0001-00-00');
var_dump($date->format('Y-m-d H:i:s')); // "-0002-11-30 00:00:00" legal
date from illegal
$date = new DateTime('-0001-01-00');
var_dump($date->format('Y-m-d H:i:s')); // "-0002-12-31 00:00:00" legal
date from illegal
$date = new DateTime('-0001-00-01');
var_dump($date->format('Y-m-d H:i:s')); // "-0002-12-01 00:00:00" legal
date from illegal
$date = new DateTime('0001-01-01'); // Correct date
var_dump($date->format('Y-m-d H:i:s'));
$date = new DateTime('-0001-01-01'); // Correct date
var_dump($date->format('Y-m-d H:i:s'));
?>
DateTime raises exceptions like month 13 or day 32, but not for some
illegal dates.
It seems this behavior is fixed/changed in 5.2.4 partially.
I was about to report this behavior as a bug, but I thought it may be
better to ask here
the reason why it behaves like this.
Is there reason that some illegal dates are allowed and result in strange
date?
One reason I can think of is MySQL. MySQL converts illegal date to
0000-00-00.
All the above script's output is out of MySQL DateTime/TimeStamp range, so
they
are converted 0000-00-00 under MySQL.
Even if PHP DateTime supports 0000-00-00 as invalid date, why don't make it
return
0000-00-00 when input is 0000-00-00?
Since these illegal dates are rather obvious, I thought there might be some
reasons behind.
ext/date/tests/bug41523-64bit.phpt
ext/date/tests/bug41523.phpt
These 2 tests use 0000-00-00 and expects the strange date.
ext/date/tests/bug62852_var3.phpt
This test unseliaizes 0000-00-00 date and raises exception.
I see controversial behavior here, unserialize raises error while new
DateTime('0000-00-00') doesn't.
If it's a bug, I'll just file it as a bug.
Thank you.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
I see controversial behavior here, unserialize raises error while new
DateTime('0000-00-00') doesn't.If it's a bug, I'll just file it as a bug.
Yasuo
Management of dates is controversial in a lot more areas than just using
the wrong calendar in prior times ;)
Each database uses it's own way to handle dates and time internally, and
most default actions are different, add to which using second as the
base for dates is just wrong anyway, but we have to live with what is
currently available.
The area that needs fixing first is the underlying OS functions rather
than continually trying to patch the top level, but we perhaps need to
document better just where the joins are ... just how many days were
there from 0BC to today ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Lester,
Management of dates is controversial in a lot more areas than just using
the wrong calendar in prior times ;)
Each database uses it's own way to handle dates and time internally, and
most default actions are different, add to which using second as the
base for dates is just wrong anyway, but we have to live with what is
currently available.
The area that needs fixing first is the underlying OS functions rather
than continually trying to patch the top level, but we perhaps need to
document better just where the joins are ... just how many days were
there from 0BC to today ...
I agree.
Under MySQL, these strange results from DateTime class would not be stored
because
MySQL does not handle year less than 1000.
Under PostgreSQL, datetime types support 4713 BC to 294276 AD. In addition,
PostgreSQL
is smart enough that convert 2015-01-32 to 2015-02-01, 0000-00-00 to
0001-01-01 BC, etc.
Therefore, these results will be stored as valid date. This is really
bad...
All invalid date should be invalid. The only possible exception may be
0000-00-00,
since many users may rely on this behavior under MySQL. We have exception
for
unserializing 0000-00-00, though.
Anyway, we need DataTime expert here.
What do you think Derick?
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net