[buddypress-trac] [BuddyPress Trac] #5781: strtotime() is evil don't use it

buddypress-trac noreply at wordpress.org
Sat Sep 3 13:44:18 UTC 2016

#5781: strtotime() is evil don't use it
 Reporter:  r-a-y         |       Owner:  r-a-y
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  2.7
Component:  Core          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |

Comment (by jdgrimes):

 I just happened to see this ticket noted in the dev chat notes posted on
 the bpdevel blog. I've been [https://core.trac.wordpress.org/ticket/37910
 playing a bit with dates and times] in WordPress recently, and this ticket
 seemed to contradict my findings, so I thought I would take a closer look.
 My conclusion is that specifying UTC when using `strtotime()` is entirely

 Replying to [comment:10 r-a-y]:
 > As for the inconsistencies with time parsing, I still think altering all
 our `strtotime()` calls to add `+0000` would be safer.  WordPress does the
 same thing (see comment:4).
 > Here's the main takeaway, all our `strtotime()` calls assume that GMT is
 the default timezone.
 > In the documentation for `strtotime()`, this is what is stated:
 > > Each parameter of this function '''uses the default time zone unless a
 time zone is specified''' in that parameter. Be careful not to use
 different time zones in each parameter unless that is intended. (emphasis

 The examples of where WordPress does this that you pointed out are all
 really ancient. They are left-over from a time when WordPress used to just
 let the server timezone be whatever it wanted to be. Today however,
 WordPress always sets the default timezone to UTC], so `date()`, `time()`,
 and `strtotime()` will return UTC times by default. This is reflected in
 admin/includes/revision.php#L168 newer code].

 This is all just FYI. But basically I'm saying that there is no need to
 switch out `strtotime()`  for `mysql2date()` just for timezone issues.

Ticket URL: <https://buddypress.trac.wordpress.org/ticket/5781#comment:18>
BuddyPress Trac <http://buddypress.org/>
BuddyPress Trac

More information about the buddypress-trac mailing list