[wp-trac] [WordPress Trac] #38342: Quick Draft: Leverage REST API endpoints

[WordPress Trac]

#38342: Quick Draft: Leverage REST API endpoints
-------------------------------------+-------------------------------------
 Reporter:  adamsilverstein          |       Owner:  joehoyle
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Administration           |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch 4.8-early      |     Focuses:  accessibility,
  needs-refresh has-unit-tests       |  javascript, rest-api
-------------------------------------+-------------------------------------

Comment (by aduth):

 Following-up on my previous comment at ticket:38342#comment:84, there are
 a few revisions that need to be made to the date formatting, particularly
 because it's hard to know (a) the true timezone offset of the incoming
 date parameter and (b) whether the return value should always be in the
 site timezone, browser timezone, or even ad hoc offsets.

 In [attachment:38342.23.diff], the value passed from dashboard.js is a
 date string in the site's timezone (`post.date`). Creating a Date object
 from the string automatically adjusts it to browser's local timezone. This
 is why the formatting function "adjusts back to GMT+0", but only works
 because what we think is GMT+0 is actually the site's timezone, even when
 it might be in-fact offset from UTC.

 Based on the incoming date values, we could make the following
 assumptions:

 - A numeric value is GMT+0 (timestamp, number of milliseconds since
 1970-01-01 00:00:00 UTC)
 - `undefined` is GMT+0 since it defaults to `Date.now` and is treated the
 same as timestamp
 - A string, if ISO8601, could include offset details. Dates from the REST
 API do not include these offset details.
 [https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators Per spec], I
 would expect they'd be treated as local browser time, but in my testing
 Chrome interprets them as GMT+0 (not sure if this is a browser-specific
 implementation detail, try `new Date( '2017-01-01T00:00:00' )` in your
 browser console)
 - A date object cannot be known with certainty, since it depends on how it
 was created. The `Date` instance itself will be in the browser's timezone,
 but if it was created from an API post object's `date` property (as in our
 Quick Drafts implementation), it would be adjusted by the site's timezone.

 So it would seem we either need conventions around how to call the
 function (must already be in a predictable offset) or add hinting options
 to allow specifying the browser, site, or ad hoc timezone offsets.

 Perhaps something like:

 `wp.formatting.date( wp.api.utils.parseISO8601( attributes.date ), 'F j,
 Y', { from: 'site', to: 'site' } );`

 Or even a fluent jQuery-like API (noting that default format should
 respect site option):

 `wp.formatting.date( new Date() ).from( 'browser' ).to( 'site' );`

 For reference, equivalent in `moment-timezone` looks something like:

 `moment.tz( '2013-11-18 11:55', 'America/Toronto' ).tz(
 'America/Los_Angeles' ).format();`

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