Bug #74652 [Opn]: strtotime() does not define behaviour of h/m/s when passed only a date

Edit report at https://bugs.php.net/bug.php?id=74652&edit=1 ID: 74652 Updated by: derick@php.net Reported by: junk at talpa dot plus dot com Summary: strtotime() does not define behaviour of h/m/s when passed only a date Status: Open Type: Bug Package: Documentation problem Operating System: ALL PHP Version: Irrelevant Block user comment: N Private report: N New Comment: I have added a test case for this: https://github.com/php/php-src/commit/fc87715950be84564a8778fefb0b4b7aa7cefd5e Previous Comments: ------------------------------------------------------------------------ [2017-05-25 14:35:08] junk at talpa dot plus dot com Description: ------------ strtotime() can be given a string which only represents a "date", rather than a specific second-granularity on that date, e.g. $foo = strtotime('25 May 2017'); Since strtotime() returns a timestamp it must decide on a sensible point on that day to use. As far as I can see, all versions (sensibly) assume 00 for any missing time elements, leading the example above to return a timestamp that represents "2017-05-25T00:00:00+00:00" This follows through if some time elements are given, but not others, e.g. strtotime('25 May 2017 10pm') => "2017-05-25T22:00:00+00:00" While it *seems* safe to rely on this behaviour, it would be better to have it as documented behaviour of strtotime(). Expected result: ---------------- Documentation clearly indicates how the sub-day elements of the timestamp are constructed in the absence of time information in the input. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=74652&edit=1