[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 mnelson4):

 == Here's another summary of the situation

 (although @jnylen0 did a good job of summarizing at the start and on
 https://core.trac.wordpress.org/ticket/39953#comment:2)

 -when drafts are saved, the `post_date_gmt` column is set to `0000-00-00
 00:00:00` as a special value that indicates "whenever it gets published"
 (it probably uses this because the database column doesn't allow `null`),
 but the `post_date` column is set to the current time, indicating when the
 draft was last updated (I don't know why it doesn't just use
 `post_modified` for that, but that's probably another discussion).


 -https://core.trac.wordpress.org/ticket/38883 did some magic so the REST
 API's `date_gmt` field for drafts, which should have been
 `0000-00-00T00:00:00` according to the `post_date_gmt` column, is
 calculated to the `post_date` column plus timezone offset. Ie, in the REST
 API, we never show `0000-00-00T00:00:00` for draft GMT dates, we show the
 actual time the draft was last updated in GMT.

 -however, it's also possible for a draft post to a scheduled date. In that
 case, its `post_date_gmt` column is set to a real time.

 -that means, over the REST API, it's impossible to know if a draft post's
 column is `0000-00-00 00:00:00`, indicating "whenever it gets published"
 aka unscheduled, or if it has a scheduled date. In the REST API, they all
 look like they're scheduled (because none have `0000-00-00T00:00:00`).

 == The possible solutions, and their PROs/CONs:

 -leave it as-is. It's up to REST API clients to keep track of whether the
 draft was scheduled or unscheduled. But that only works when the REST API
 client created the draft. If the draft was created in the wp-admin, the
 REST API client has no way of knowing if it scheduled or unscheduled. But
 it does keep the REST API simpler.

 -add a new field, called something like `date_floating`, which would
 indicate if the draft internally has a scheduled date or is unscheduled.
 The downside to this is it's a bit messy deciding what to do when a draft
 is submitted with a `date_gmt` AND `date_float=true`, because
 `date_floating=true` means we should totally ignore whatever is submitted
 for `date_gmt`. Also, this adds yet another field. Also, it's inconsistent
 with the database (although we're already inconsistent). But it seems
 backwards compatible and makes it easy to distinguish between
 scheduled/unscheduled drafts

 -when requesting a post in the "edit" context, don't do the magic from
 https://core.trac.wordpress.org/ticket/38883 (that makes it so the REST
 API field `date_gmt` is calculated from the column `post_date` plus
 timezone offset) and instead leave `date_gmt` be null, like it was before
 that ticket. This is quite consistent with the database, but might be
 backwards incompatible for REST API clients that didn't expect `null` for
 `date_gmt` (I think that would be neglegible, as before
 https://core.trac.wordpress.org/ticket/38883 it often had `null` in it).
 Also, it's a bit strange having `date_gmt`'s value be dependent on the
 request context.

 == Mike's Opinion
 It feels like we're putting more paint over a crack in the foundation- it
 won't ever be pretty. But I like adding a new field or using `null` for
 unscheduled drafts in the `edit` context equally. Both add a bit of
 complexity to understanding the REST API, but provide the needed feature.

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