[wp-trac] [WordPress Trac] #33397: Add constant MONTH_IN_SECONDS

WordPress Trac noreply at wordpress.org
Tue Aug 18 01:38:45 UTC 2015


#33397: Add constant MONTH_IN_SECONDS
-------------------------+-----------------------------
 Reporter:  toscho       |      Owner:
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 When the time constants were introduced in #20987, `MONTH_IN_SECONDS`
 wasn't included because the core didn't it need at that time, and each
 month has a different length, so it would never be accurate.

 I think we should rethink that decision:

 1. Now, we do use `30 * DAY_IN_SECONDS` in `human_time_diff()` to
 calculate a "month". All the other time units are expressed in pure
 constants in that function, this one stands out. This is inconsistent.

 2. The other values aren't accurate either, (think DST, leap
 years/seconds, see [http://infiniteundo.com/post/25326999628/falsehoods-
 programmers-believe-about-time Falsehoods programmers believe about time]
 to get some ideas). Precision never was the point of these constants,
 their value is convenience. If you need an accurate time, use better tools
 like [http://php.net/manual/en/class.datetime.php DateTime].

 3. Global constants are an API. An API has to be predictable. Right now,
 we always have to remember the "missing interval", or we have to add it in
 our plugins. That's not good.

 My suggestion is to use a rounded value of 30 days like
 `human_time_diff()` does already, and maybe add a note to
 `wp_initial_constants()` reminding developers about potential problems
 with these simplified values.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/33397>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list