WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#39855 new defect (bug)

REST API: Add timezone offset to all date responses

Reported by: jnylen0 Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 4.7
Component: REST API Keywords:
Focuses: rest-api Cc:

Description

Currently the REST API returns dates in the following format: 2016-12-12T14:00:00. This should really be 2016-12-12T14:00:00Z for date_gmt or 2016-12-12T14:00:00-05:00 for date.

Date/time values should always be stored and processed with their corresponding timezone offset (or at least a best guess). This accomplishes a few things at once:

  • Exposes the best guess for the timezone offset of the date (non-UTC) field of a post or comment. This information is currently not available anywhere else in the API.
  • Makes client-side datetime manipulation much easier and less error-prone. See ticket:38342#comment:86.

If we are going to make this change we need to do it soon. Milestoning for 4.7.3 for discussion.

Change History (7)

#1 follow-up: @dshanske
2 years ago

There are a bunch of unrelated timezone issues that I would suggest we clean up concurrently to this. It is too common for WordPress times to be generated without proper timezone data.

#2 in reply to: ↑ 1 @jnylen0
2 years ago

Replying to dshanske:

There are a bunch of unrelated timezone issues that I would suggest we clean up concurrently to this.

Let's keep this ticket specifically focused on the API. Back-compat is another complicating factor for other parts of WordPress; less so for the API because it's still fairly new and we agreed to make some backwards-incompatible changes in early 4.7.x releases for things we missed in 4.7.0.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


2 years ago

This ticket was mentioned in Slack in #core-restapi by jnylen. View the logs.


2 years ago

#5 @jnylen0
2 years ago

  • Milestone changed from 4.7.3 to Awaiting Review

We chatted about this a bit more in Slack. Still no consensus on what to do about it. Comment from @rmccue explaining the current behavior:

The main reason we dropped the timezones was so we didn't expose data we have no real authority over

with the noted drawback that this makes working with the returned dates more difficult.

The combination of #38883 and #39854 would probably be a reasonable workaround here.

Given the lack of consensus, and the fact that this change could be a fairly significant backwards-compatibility break, and finally the fact that 4.7.3 is upon us, I'm going to remove it from the milestone.

We could also consider a ?_timezones=true parameter that adds timezones to date responses, though I'm not crazy about that idea either.

#6 @joehoyle
2 years ago

We could also consider a ?_timezones=true parameter that adds timezones to date responses, though I'm not crazy about that idea either.

Yeah not wild about that. I think #39854 is probably the best we can hope for here.

This ticket was mentioned in Slack in #core by jnylen. View the logs.


2 years ago

Note: See TracTickets for help on using tickets.