WordPress.org

Make WordPress Core

Opened 3 weeks ago

Last modified 3 weeks ago

#44482 new enhancement

Problem with interpretation of U and G formats in dates as WP timestamps

Reported by: Rarst Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: trunk
Component: Date/Time Keywords:
Focuses: Cc:

Description

WordPress mostly follows upstream date() for date formatting. However there is a significant deviation with U and G.

The PHP manual's definition for these are:

  • U Seconds since the Unix Epoch (January 1 1970 00:00:00 GMT)
  • G 24-hour format of an hour without leading zeros

WordPress has quite a different interpretation. First, it calls both of these Unix timestamp formats. However what it tends to return for them are "WordPress timestamps", effectively a sum of Unix timestamp with timezone offset, produced either explicitly (by adding gmt_offset to a Unix timestamp) or implicitly (by parsing stored non-GMT time as GMT input).

The only time when WordPress timestamp is equal to Unix timestamp is when it is produced with zero offset or parsed from GMT time.

This creates incredible challenge in correct operation, interoperability with PHP, and developer experience. It isn’t humanly possible to be constantly aware is the chunk of numbers has meaning as Unix timestamp or WP timestamp, especially since inline documentation constantly mis–names latter as former.

Since some API functions expect WP timestamps at this point backwards compatibility makes it impossible to just change these formats to actual Unix timestamps in existing functions.

So far I see the only way to salvage this:

  1. Deprecate every API function that returns or consumes WP timestamps in response to G/U formats (date_i18n() and mysql2date() are huge chunk of that).
  2. For functions that can produce correct Unix timestamps for G/U formats, deprecate combinations of arguments that lead to WP timestamps, such as get_post_time() with $gmt = false.

Yes, this pretty much obliterates existing Date/Time API. However under current backwards compatibility commitments it would be impossible to keep WP timestamps and move towards meaningful and reliable operation in it.

Change History (1)

#1 @Rarst
3 weeks ago

#43269 was marked as a duplicate.

Note: See TracTickets for help on using tickets.