|   | 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 Group All rights reserved. | Last updated: Sun Oct 26 23: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.