|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2017-05-25 14:58 UTC] derick@php.net
[2017-05-26 12:44 UTC] cmb@php.net
-Type: Bug
+Type: Documentation Problem
-Package: Documentation problem
+Package: Date/time related
[2022-06-02 15:30 UTC] git@php.net
[2022-06-02 15:30 UTC] git@php.net
-Status: Open
+Status: Closed
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Fri Oct 24 01:00:02 2025 UTC |
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.