[wp-trac] [WordPress Trac] #39953: REST API: Add `date_floating` flag for posts

[WordPress Trac]

#39953: REST API: Add `date_floating` flag for posts
------------------------------------------+------------------------------
 Reporter:  jnylen0                       |       Owner:  (none)
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  REST API                      |     Version:  4.7
 Severity:  normal                        |  Resolution:
 Keywords:  needs-patch needs-unit-tests  |     Focuses:  rest-api
------------------------------------------+------------------------------

Comment (by earnjam):

 After thinking on it a bit more, I'm closer to agreeing with @jnylen0
 here.

 I'm not crazy about adding a separate flag for this, but the dates
 shouldn't have been used in this way from the beginning. In my opinion
 there should have been no dates stored for either `post_date` or
 `post_date_gmt` until published or manually set and `post_modified` and
 `post_modified_gmt` should have been used instead. You could even argue
 that from the beginning the REST API should have returned null values for
 both `date` **''and''** `date_gmt` if there was no `post_date_gmt` stored,
 since it would mean there wasn't a **''true''** date set for the post yet.
 The shim wasn't really needed IMO because you should have been using the
 `modified_gmt` value when you needed a date for an unpublished/unscheduled
 draft. But here we are.

 At this point, changing the way we supply `date_gmt` in the REST API now
 does add potential for breakage even with the `edit` context, as there
 might be clients using `edit` context now and not expecting a null value
 there.

 I suppose we could make a pretty good guess that it's supposed to be a
 floating date when looking at the API response right now if the post
 status is `draft` or `auto-draft` and `date` is identical to `modified`.
 The only way I think that scenario would not be true is if you manually
 set the date to the exact second you saved the draft. Highly unlikely, but
 it still feels potentially unreliable.

 The only way I see out of this while maintaining full back-compat is some
 kind of flag.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39953#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform