REST API: Improve date updates if both `date` and `date_gmt` are set

[jnylen0]

Currently, if you set both the date and date_gmt fields when creating or updating a post or comment, the date field will take precedence and the date_gmt field will be ignored.

This behavior isn't ideal because when either of these two dates is specified, the other is also updated based on the site's timezone offset.

If both date and date_gmt are specified, and the two values do not match according to the site's current timezone offset, there are a couple of options for improving the behavior:

• Update the date fields exactly as requested, even though they will not match the site's current timezone offset.
• Return an error.

[nerrad]

I would prefer either:

• if both are specified, prefer gmt value over date value.

OR

• throw an error if both are specified.

From a back compat standpoint, the latter option seems safer.

[nerrad]

Ideally post_date should be a readonly field.

[jnylen0]

Ideally the date / post_date field wouldn't even exist, and we would store all dates as UTC, and also store timezone offsets where needed. That ship sailed long ago.

In most of WordPress, including wp-admin, post_date is the default field, and post_date_gmt is basically an afterthought. From this perspective, the existing behavior of preferring the date value makes more sense than preferring the date_gmt value.

This isn't likely to be a big deal either way, just something we could definitely handle better.

[rmccue]

Replying to jnylen0:

If both date and date_gmt are specified, and the two values do not match according to the site's current timezone offset, there are a couple of options for improving the behavior:

• Update the date fields exactly as requested, even though they will not match the site's current timezone offset.
• Return an error.

One other condition should be valid: if they match the existing values, then do not alter it, even if the timezone has changed since. (Use case: sending exact response data back to server.)

I think the best approach is: if the dates do not match the existing values, and the date/date_gmt are not exactly gmt_offset apart, return a 400 Bad Request error indicating invalid dates.

[mnelson4]

What if I'm on a holiday in a different timezone when I wrote the post? Might it make sense for the date and date_gmt to not differ by gmt_offset? (Eg I'm usually in New York, UTC-5, but I went on a trip to Los Angeles, UTC-8, and wrote a post at 12pm while there, so it's date is 12:00, and its date_gmt is 20:00). If that's a valid case, then when someone provides both the date and date_gmt, we should probably just use those two values exactly, and not apply gmt_offset to either.

Or maybe the dates should just always be in the site's timezone, regardless of the author's local time? If so, disregard this comment.

[jnylen0]

Replying to mnelson4:

Or maybe the dates should just always be in the site's timezone, regardless of the author's local time?

For better or worse, this is the way WP handles dates. Really we should just store UTC with the appropriate offset(s), but it's too late for that.

Still, I'm not really opposed to allowing clients to set both date and date_gmt, under the assumption that if they want to do that, they know what they are doing. As you mentioned, this does provide a way to store the timezone offset of a post.

@rmccue what do you think? Edit for clarity: why would you suggest returning an error instead of allowing the operation to succeed?