[wp-trac] [WordPress Trac] #39256: REST API: Multiple issues with setting dates of posts

[WordPress Trac]

#39256: REST API: Multiple issues with setting dates of posts
--------------------------+----------------------------------------
 Reporter:  jnylen0       |      Owner:
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  4.7.1
Component:  REST API      |    Version:  4.7
 Severity:  major         |   Keywords:  needs-patch has-unit-tests
  Focuses:                |
--------------------------+----------------------------------------
 Setting the date of a post while creating or updating it is broken in at
 least two ways.

 ----

 '''First''', the value that comes back from the API does not contain a
 timezone (some recent discussion about this
 [https://wordpress.slack.com/archives/core-restapi/p1481564306000735 in
 Slack]).  This is not great, but possibly reasonable, since these values
 are stored in the database without a timezone offset.

 However, when these values are pushed back to the `date` field of a post
 via the API, they are interpreted as GMT by
 [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rest-
 api.php?rev=39588#L746 the `rest_parse_date` function].

 This means that whenever you set the `date` of a post based on the value
 that came back from the API, it ends up offset by the site's `gmt_offset`.
 Example requests (read in reverse order):

  [[Image(https://nylen.io/rest-api-post-dates-offset.png, 500px)]]

 ----

 '''Second''', it's impossible to update the date of a draft - the request
 succeeds but the date is not changed.  I haven't yet looked into why this
 is broken.  Creating a draft with a specific date seems to work, though I
 think it may break core's flag for updating a post's date when the post
 changes (see "complication" below).

 ----

 To address the first issue, we need to stop interpreting dates without
 timezones as UTC, and I think we should also include our best guess for
 the timezone offset with each date value.  (For `date` this will be the
 site's `gmt_offset`, which is not currently available anywhere in the API;
 for `date_gmt` this will be zero).

 One complication in addressing the second issue is that WP core uses a
 zero/null `date_gmt` to indicate that the `date` field should be updated
 when a draft is saved.  See also #38883 and ticket:5698#comment:14

 I'll work on a full patch next, but since it seems likely we'll need to
 discuss the best approach, I'm starting this ticket off with failing test
 cases first.  We also need tests for `rest_parse_date`,
 `rest_get_date_with_gmt`, and any other related methods.

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