[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