REST API: Do not update date when preparing post if date is known to be "floating"

[jnylen0]

If the post_date_gmt field for a draft is 0000-00-00 00:00:00, WP core uses this as a marker to update the date of the draft to the current time whenever the post is updated. See ticket:5698#comment:14.

After #38883, there's not a way to determine whether a post is in this status (being able to use the date_gmt field is far more important). To restore this ability (and also add the ability to modify this status, which has never been present in the REST API), we need to add a new boolean field.

Storing this piece of information ("should we update the date of this post when it's saved?") in a separate field is the way this functionality should have been implemented from the beginning. It's probably too late to make this change for WP core, but we can at least provide a better design in the REST API.

[nerrad]

I'm still trying to decipher what the purpose of this ticket is so looking for clarification.

So are you saying prior to the changes in #38883, the marker for whether a date got set to the current date when a draft post has its status changed is the post_date_gmt field being 0000-00-00 00:00:00 and AFTER the changes, that field has an actual specified date so there's no reliable marker to indicate updating the post to the current time of when the request is changing the post status?

If so, I'm not sure I like the idea of adding a flag. Instead I think the client should be responsible for setting the date period. I realize there may be implications with this stance but I don't want to respond to those until I know that my interpretation of the purpose for this ticket is correct.

[jnylen0]

When you create a draft in WP, whether via wp-admin or the REST API, it has a post_date_gmt value of 0000-00-00 00:00:00.

When you update the draft again, most importantly when you publish it, WP looks for this special value of post_date_gmt. If it's present, the post date is reset to the current timestamp (ref). Usually this is what you want (by default, a post is dated when it's published, not when its draft is created).

This behavior dates back to [8920], we can't change it in the WP internals.

If you update the date of the draft before publishing it, whether via wp-admin or the REST API, both the post_date and post_date_gmt fields are set to the new date you've specified. It's currently possible to undo this operation and set the date back to "floating" in wp-admin, but this hasn't been possible via any public release of the REST API.

After #38883, there's no way to tell via the REST API whether a post actually has an internal post_date_gmt value of 0000-00-00 00:00:00 or not, because if it does, we use the post_date field to calculate and provide a reasonable value for date_gmt. Guaranteeing a usable value in the date_gmt field is many times more useful than being able to know the status of this internal flag.

The new field proposed in this ticket would contain (and allow updating) this extra piece of information about the internal state of a post. If the new field has a value of true, then the post is a draft with a post_date_gmt value of 0000-00-00 00:00:00; otherwise, the new field is false.

Something like date_floating might make a better name for this field.

[nerrad]

Thanks for explaining things, I was aware of how things worked on the WP side of things but clarifying what prompted the proposal in this ticket helps.

After the explanation I'm still wary of the need for an flag for auto-updating (whatever its called) on the endpoint. I believe we need to be careful about controlling behaviour of data properties based on some other flag in the package. It's more predictable and sets expectations better I think if the behaviour of the endpoint is that whatever you have the date set at on that field during an update is what gets saved.

Practically that means that its up to the consumer to save the current post_date_gmt value to the equivalent of "now" in the PUT call if they want that to be the publish date (when publishing) the post.

The other concern with setting a flag for controlling this behaviour is whether this is something applicable only on the post endpoint, or if its something that would apply to any custom post type (pages? menus?) If its only on the "posts" endpoint, then that does changing the schema for a post_type request depending on what "type" it is matter? If it's including it on every post_type response, is it a fair assumption that all post types will follow the same behaviour patterns as a post?

[jnylen0]

Replying to nerrad:

After the explanation I'm still wary of the need for an flag for auto-updating (whatever its called) on the endpoint. I believe we need to be careful about controlling behaviour of data properties based on some other flag in the package. It's more predictable and sets expectations better I think if the behaviour of the endpoint is that whatever you have the date set at on that field during an update is what gets saved.

This bundling of multiple pieces of information/functionality into a single field is the way WP currently behaves, and it's broken. It should have been a separate field from the start.

Practically that means that its up to the consumer to save the current post_date_gmt value to the equivalent of "now" in the PUT call if they want that to be the publish date (when publishing) the post.

This isn't going to work because it would break the default behavior where a post is dated when it is published.

The other concern with setting a flag for controlling this behaviour is whether this is something applicable only on the post endpoint, or if its something that would apply to any custom post type (pages? menus?) If its only on the "posts" endpoint, then that does changing the schema for a post_type request depending on what "type" it is matter? If it's including it on every post_type response, is it a fair assumption that all post types will follow the same behaviour patterns as a post?

This applies equally to every post type which has a concept of a draft (not attachment).

[joehoyle]

-1 on the proposed solution, but I don't have a better suggestion right now. That's probably totally not very helpful, but I think this additional field would also suck.

[jnylen0]

@joehoyle what are your concerns with this approach? This is an extra piece of functionality, so it should have lived in an extra field from the beginning.

Note that without some kind of implementation for this feature it won't be possible to build a full-featured editor using the REST API.

[earnjam]

This just came up in Gutenberg because we can't reliably tell if a draft post has a date set or not to know what to display in the publish panel as the date.

​https://github.com/WordPress/gutenberg/issues/7195

One option is to allow the date_gmt value be null in the edit context. Not necessarily ideal, but it continues the pattern used by the classic editor.

[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 fixed 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 "date floating", or if it has a fixed date. In the REST API, they all look like they all have a fixed date (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 had a floating date or a fixed one. 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 has a floating date or a fixed one. 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 floating date or is fixed. 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 drafts with a floating date or a fixed date

-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 drafts with floating dates in the edit context equally. Both add a bit of complexity to understanding the REST API, but provide the needed feature.

[jnylen0]

leave it as-is. It's up to REST API clients to keep track of whether the draft was scheduled or unscheduled.

This is not going to work, because of the case you mentioned: different clients editing the same post.

when requesting a post in the "edit" context, don't do the magic from #38883 ... [but] it's a bit strange having date_gmt's value be dependent on the request context.

Let's not do this either. Inconsistency bad. :)

add a new field, called something like date_floating

This is still my preferred solution. I also haven't heard a name I like more than date_floating.

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.

I think this should be a 400 Bad Request because the client is providing inconsistent information regarding what it wants the API to do. Again: inconsistency = bad.

It feels like we're putting more paint over a crack in the foundation- it won't ever be pretty.

No argument here. Still, I think trying to fix this across all of WP would be very difficult and would cause a surprising amount of breakage.

Both add a bit of complexity to understanding the REST API, but provide the needed feature.

This little flag is complexity of the application, which should be reflected in the API. It is a separate piece of information from the draft's date, so the simplest way for consumers of the API to understand this new feature is to use a separate field.

[jnylen0]

I think this should be a 400 Bad Request because the client is providing inconsistent information regarding what it wants the API to do. Again: inconsistency = bad.

I am revising my opinion on this. If date_gmt is set and date_floating is true, then that's fine. Internally, we convert date_gmt to site local time, and set date accordingly. Then we set date_gmt to the null value.

Not ideal, but I think it's the best we can reasonably do.

[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.

[jnylen0]

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.

Yep, this is getting closer to what the ideal design could have been from the beginning.

There are really several separate dates in play here, which may or may not be equal in various circumstances.

• Published/updated date - post_date and post_date_gmt. Usually.
• Modified date - always read-only, unless you try really hard and edit this via a direct db query.
• Creation date - currently post_date serves this role for drafts... until the draft is published, then the creation date may be lost, and post_date and post_date_gmt suddenly mean "date published".

Complicated for sure. I guess we could do some kind of hack to add created and created_gmt, but it would be even more complicated, and the field values would often be inconsistent or missing since there just isn't a natural way to separate and store these separate pieces of information.

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

+1

[mnelson4]

+1 to flag.
Is there something we’re oberlooking @nerrad (who I actually know is on holiday for another week) or @joehoyle ?

[mnelson4]

Actually one comment though: the name scheduled_to_publish or just scheduled would be a more intuitive name than date_floating, speaking as one less familiar with the established jargon. I think this name would make more sense on published posts too.
I think this name corresponds especially well to the post editing page, when posts are scheduled or not.
To be exact, when the column post_date_gmt=0000-00-00 00:00:00, or when the post was already published, it would be false, but when the post is a draft and has any other post_date_gmt, it would be true.
Thoughts on this name suggestion?

[earnjam]

Replying to mnelson4:

Actually one comment though: the name scheduled_to_publish or just scheduled would be a more intuitive name than date_floating, speaking as one less familiar with the established jargon. I think this name would make more sense on published posts too.
I think this name corresponds especially well to the post editing page, when posts are scheduled or not.
To be exact, when the column post_date_gmt=0000-00-00 00:00:00, or when the post was already published, it would be false, but when the post is a draft and has any other post_date_gmt, it would be true.
Thoughts on this name suggestion?

scheduled is a post status that essentially denotes that a user has manually set a date in the future and wants it to switch to publish at that time. When a post is transitioned to publish, scheduled or trash status, it should always have a post_date_gmt value stored. So I don't think that term works here. Its sort of a reserved word meaning "publish pending".

In this case, we're just looking at posts which are still in the auto-draft or draft status, and a date has not yet been set either by the user, or by transitioning to publish or trash.

To clarify, you could have a post that that is still a draft, but has a date set for the future, but it's still not technically "scheduled". A user may not be ready for it to auto-transition to published at that time yet. I think using scheduled: true in that situation would be confusing.

I think date_floating works because it signifies that a permanent date hasn't been affixed yet. I'm not tied to that, but can't think of a better alternative at the moment.

[mnelson4]

I think using scheduled: true in that situation would be confusing.

oooh ok. Ya I misunderstood. So draft posts with a date are like scheduled/future posts, except the author clicked "Save Draft" instead of "Schedule". So basically post_date_gmt=0000-00-00 00:00:00 indicates what could be called a "scheduled draft", right? (Although I don't think anyone else uses that term.)
Anyways, ya ok, so date_floating is better.

[mnelson4]

This was discussed today in Slack: ​https://wordpress.slack.com/archives/C02RQC26G/p1534439759000200

Takeaways: @kadamwhite and @nerrad (maybe @timothybjacobs too?) were opposed to adding a new field, because

I’m 👎 on the flag, feels like we shouldn’t need it. Looking for prior art from other API’s :)

(from @kadamwhite)and

I don’t think the flag is self-explanatory enough

And it feels like we’re exposing WP insufficiencies in the endpoint with a flag.

(from @nerrad)

[danielbachhuber]

I don't love the name date_floating, but I don't see another way around the problem at this point. My preferred naming would denote its boolean nature (and it would be explicitly defined a read-only field too).

Filing against WordPress 5.0 milestone because we need to sort this out one way or another by then.

[TimothyBlynJacobs]

We discussed this in the rest-api chat earlier today.

One of the options mentioned earlier in the ticket by @earnjam looks like it should work.

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.

While that solution might seem slightly weird at first glance, I think it makes sense conceptually. If the date and the modified date are the same, then we're still working on the post because those are both updated at every write. As mentioned we don't have an actual created_at date. This would save us having to add the new field.

We couldn't figure out a time when those two dates wouldn't match and in testing it looked like it would work to fulfill Gutenberg's needs. We should probably make some adjustments to the prepare_item_for_database() method to not set the edit_date property if the two dates are the same. Otherwise, just PUTing back the received response will cause the internal post_date_gmt field to be updated and not remain as 0000.....

In the current UI it does not appear to be possible to go back to a "date floating" state. However, @mnelson4 brought up that it appears that you can reset back to that state in the [Calypso UI](​https://drive.google.com/file/d/1tDB68iNGFZUfJ0cWmklKTJqpCSg3w1uE/view?usp=sharing). Do we want to support this? @danielbachhuber mentioned that this field would be readonly which to me indicates we shouldn't. If we wanted to, though, we could support setting the date to null.

[kadamwhite]

I support @TimothyBlynJacobs' most recent proposal to assume a floating date when date and modified_date are the same. The edge-case where the date is manually set to the _exact second_ you save a draft feels like an acceptably minimal risk, and I'm still strongly opposed to forcing a new property onto a response that only accomplishes the same result as a simple equality check.

In Gutenberg we do not actually pass a date field on save unless a date has been manually set, so I believe the code to handle this implementation would be as simple as this:

+function isFloatingDate( { date, modified, status } ) {
+       if ( status === 'draft' || status === 'auto-draft' ) {
+               return date === modified;
+       }
+       return false;
+}

-function PostScheduleLabel( { date } ) {
+function PostScheduleLabel( props ) {
+       const { date } = props;
+       const floating = isFloatingDate( props );
        const settings = getSettings();
-       return date ?
+       return date && ! floating ?
                dateI18n( settings.formats.datetime, date ) :
                __( 'Immediately' );
 }
@@ -15,5 +24,7 @@ function PostScheduleLabel( { date } ) {
 export default withSelect( ( select ) => {
        return {
                date: select( 'core/editor' ).getEditedPostAttribute( 'date' ),
+               modified: select( 'core/editor' ).getEditedPostAttribute( 'modified' ),
+               status: select( 'core/editor' ).getEditedPostAttribute( 'status' ),
        };
 } )( PostScheduleLabel );

We would indeed still need to update our item preparation code to make the same assumption if a date and modified value _are_ passed back to the server in the response, but that should also be a similar patch.

I think this is the right way forward. Thank you @TimothyBlynJacobs and @earnjam for thinking through it so thoroughly!

[kadamwhite]

Created ​https://github.com/WordPress/gutenberg/pull/9967 to propose the Gutenberg-side fix. @TimothyBlynJacobs do you have bandwidth to tackle the PHP-side change? If not I may be able to address later this week.

[TimothyBlynJacobs]

@kadamwhite Yep!

[mnelson4]

Thanks @kadamwhite for the direction. Good to hear we have an easy solution. I do think we should take the time to document this gotcha for developers not following trac. Eg maybe on ​https://developer.wordpress.org/rest-api/reference/posts/ ?

[kadamwhite]

I'm not sure whether this should be in reference (which is largely auto-generated at present) or in a dedicated FAQ or more human-oriented guide page. I agree it should be in the handbook; that content is currently managed through ​https://github.com/wp-api/docs should you have any bandwidth to draft something, otherwise we'll tackle that once the ticket is closed out. Thanks!

[mnelson4]

I took this for a spin and basically double-checked what the unit tests are already asserting:

• on a date-floating post, if you POST the same date you received in a GET request, it will remain date-floating

• on a date-floating post, if you POST a different date than what you received in a GET request, it will no longer be date-floating

• on a non-date-floating post, it will remain a non-date-floating post regardless of what you provide for date.

So 👍

However, I would think we'd want to also support transitioning back to date-floating (like I noted is supported in Calypso, and so is supported by the WP.com API). Eg for a non-date-floating post, if you passed an identical date and modified dates, the post should revert to date-floating (the database columns post_date and post_date_gmt are updated with the POST date value, the POST's modified value is ignored and post_modified and post_modified_gmt are instead updated to the current time). Should I make a separate issue for supporting updating a non-date-floating post to be date-floating again?

[TimothyBlynJacobs]

We could also support passing null as a date to reset back to no fixed date.

[kadamwhite]

We could also support passing null as a date to reset back to no fixed date.

It does not need to be a part of this ticket I think given that it's a longstanding issue (see #8368), but this is the idea I came to as well, and I really like this idea.

[danielbachhuber]

Replying to TimothyBlynJacobs:

We could also support passing null as a date to reset back to no fixed date.

Is null the correct value, over false or an empty string?

[mnelson4]

Created https://core.trac.wordpress.org/ticket/44975 for the ability to switch a non-date-floating post back into a date-floating post. So this ticket can just focus on allowing posts to remain "date floating" even when the date parameter is provided in update requests.

[kadamwhite]

Renaming issue based on the decided solution.

[kadamwhite]

To clarify the renaming of the issue: as we can infer date_floating status by comparing date and modified values when receiving an API response or accepting an API update object, we will use that approach instead of adding a date_floating flag. The desired behavior is now present in Gutenberg following the merge of ​https://github.com/wordPress/gutenberg/pull/9967 and the latest patch on this ticket will ensure that other clients experience the same behavior even when passing a full post object back to the server.

[kadamwhite]

I believe this is ready but since it is not technically required for Gutenberg to function — merely for any other client to function the same as Gutenberg — per discussion with @johnbillion in Slack, I am not going to land it at this time. I am adding "commit" keyword so that we can evaluate it along with other REST API changes slated for 5.0.

[pento]

Have y'all explored the option of adding a "Scheduled Draft" post status? It seems like that would solve all of the problems presented here.

For a post with a post_status of draft:

• When requested, the object will have post_date and post_date_gmt appear as they currently are.
• When updated, with post_status still set to draft, post_date_gmt will be ignored, regardless of if it's passed.
• When updated, with post_status changed to scheduled-draft, post_date_gmt will be saved as passed. If post_date_gmt isn't passed at the time, I'm not really fussed if that's an error, or if it uses now(), instead.
• When updated, with post_status changed to publish, behaviour stays the same as it currently is.

For a post with post_status of scheduled-draft:

• When requested, the object will have post_date and post_date_gmt appear as they currently are.
• When updated, with post_status still set to scheduled-draft, post_date_gmt will be saved if it's passed, or unchanged if it isn't.
• When updated, with post_status changed to draft, post_date_gmt will be cleared.
• When published, post_status will be set to publish if post_date_gmt was in the past, or future, if it's in the future.

From a UI perspective, we don't need to make any changes, really. scheduled-draft can be a hidden post status, it doesn't show in the status dropdown. The application should choose between draft and scheduled-draft based upon if the author has changed the post date, or clicked a "reset post date" button, or something of that nature. This resolves both this issue, and #44975.

Back compat is a little trickier, as there are a lot of places that assume that the post statuses of drafts will only be draft. I think we can cover most usage pretty easily, though. get_post() could change the returned post status from scheduled-draft to draft, unless a flag is passed by code that knows how to deal with the two types of drafts. This also covers get_posts(), as WP_Query runs get_post() on the returned results.

[mnelson4]

+1 @pento, that would be a much more proper solution IMO, but I think backward compatibility would just be the problem. If BC issues can be satisfactorily resolved, that sounds great.

[danielbachhuber]

Moving this ticket to 5.1. Because it's not critical for Gutenberg, we don't have to make an immediate decision and have a bit of time to continue to think about it.

[earnjam]

This came up again in Gutenberg here: ​https://github.com/WordPress/gutenberg/issues/13176

Because of the way we're making an assumption in Gutenberg on whether the date is floating based on a couple of specific statuses, we can't account for floating dates with any custom post statuses.

Adding another new type of draft status as Gary suggested above wouldn't help in that case either, unfortunately.

[mnelson4]

What about adding allowing register_post_status() to support another arg named something like "date_floating"?

If it were set to true, it would indicate the date can be floating (like on draft, auto-draft, and pending), but if false then it indicates the date can't be floating (like published and private).

Then we would expose that on wp/v2/statuses, and API clients would know how to account for floating dates for posts of that particular status.

[pento]

An extra arg for register_post_status() is interesting. We need to explore this issue further, but it won't be happening in 5.1, with beta 1 due out this week.

[desrosj]

This still needs to be looked into more. Since 5.2 beta 1 is in less than 2 days, let's punt.

[mnelson4]

Includes 39953.patch's changes, and adds date_floating to register_post_type and the REST API post statuses responses

[kadamwhite]

Ran phpcbf on 39953.1.diff

[kadamwhite]

In 46252:

REST API: Introduce date_floating property on status endpoint response objects.

Expose a date_floating property on all status objects to permit clients (including the block editor) to make correct decisions about date handling for posts of varying status.

Props mnelson4, earnjam, kadamwhite, jnylen0, nerrad, pento.
See #39953.

[kadamwhite]

I have landed the most recent patch here, but left the ticket open (and will add needs-dev-note) until we have a chance to discuss whether this "completes" the intent of the ticket, in which case future work can occur within the Gutenberg repository.

[TimothyBlynJacobs]

Added a patch that marks the pending post status as having a floating date as well. See ​https://github.com/WordPress/gutenberg/issues/13176.

Creating a new ticket to update the hardcoded list of statuses in wp_insert_post as well: ​https://github.com/WordPress/wordpress-develop/blob/9a105cf0049e7bc5a0da1ba05c01373f566a7335/src/wp-includes/post.php#L3729

[kadamwhite]

In 46274:

REST API: Mark "pending" status as date_floating.

See: ​https://github.com/WordPress/gutenberg/issues/13176

Props TimothyBlynJacobs.
Fixes #39953.

[kadamwhite]

I believe that this (along with the new issue #48113) completes the PHP side of the date floating support changes. Marked as closed in [46274].

[kadamwhite]

In 46275:

Coding Standards: Fix WPCS issue in [46274].

See #39953.

[SergeyBiryukov]

In 46280:

REST API: Use delta comparison for floating date tests added in [46252] to avoid race conditions.

See #39953.

[kadamwhite]

Dev note: ​https://make.wordpress.org/core/2019/10/16/the-rest-api-in-wordpress-5-3/

[SergeyBiryukov]

In 47080:

Tests: Replace date() with gmdate() in WP_Test_REST_Posts_Controller tests.

Follow-up to [45424], [46252].

See #46438, #44491, #39953.