This repository was archived by the owner on Sep 24, 2018. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 24, 2018. It is now read-only.
The date field of GET /comments should contain either a 'Z' time offset signature. #1675
Description
Environment
WordPress: 4.3.1
WP REST API: 2.0-beta 4
Machine: Chassis with VirtualBox 4.3.28 as its VM backend
How To
Using the following snippet:
#!/bin/sh
http POST <url> author_name='Shell' \
author_email='shell@xd.cc' \
author_url='http://goog.le' \
content='wp rest api rocks!' \
date='2015-10-22T12:00:00Z' \
post=<pid> \
parent=0
The date field of the response will be 2015-10-22T12:00:00, so does GET /comments.
According to the ECMAScript 2015 spec:
If the time zone offset is absent, the date-time is interpreted as a local time.
Thus, the returned date string is a local time string instead of the originally-submitted UTC time string for any browser implementing this spec.
Activity
danielbachhuber commentedon Oct 25, 2015
Thanks for the detailed report.
Dates are returned as ISO8601/RFC3339:
WP-API/lib/endpoints/class-wp-rest-comments-controller.php
Lines 473 to 474 in 8f55847
The timezone is omitted because:
This decision was made in 6d0ad76. I'll flag this for discussion so we can reverify the decision.
You can use the
date_gmtvalue instead, but we'll need to expose it in the view context first. #1690southp commentedon Nov 3, 2015
Hi @danielbachhuber ,
Thanks for bringing it further. As long as there is no timezone information saved in the first place, I think it is still the right call to not including such an information. Exposing
date_gmtvalue fits my purpose very well, as a plus it also disambiguates the purpose ofdate.Lastly, the document states the
dateas:I think it might be clearer if we put it as something like:
danielbachhuber commentedon Nov 3, 2015
Sounds good — submitted in #1715
southp commentedon Nov 4, 2015
Thanks for the help. It looks even better 👍
rmccue commentedon Nov 9, 2015
Forgot to note, this is actually a recent change; previous specs have treated timezone-less strings as UTC time. Weird that the spec has broken backwards compatibility here.