Add gmt_offset as a REST API setting

[jshreve]

The timezone string can be seen and updated via the REST API, but there is no way to get the GMT offset (which I would imagine is more more valuable for calculating things). There is also no way to update it (aka manual offset).

The attached patch is one way to fix it. It makes sure to clear out the timezone string if you are manually overriding/setting the offset. I'm not sure if what I have is the best way to handle that case for the API, but I took a stab at it. If a timezone string is set, the offset is correctly returned for that timezone.

[jshreve]

This is where settings are linked in wp-admin: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/options.php?rev=39308#L176

[jnylen0]

We need a way to expose gmt_offset and other site info, but currently we intend the settings endpoint to be used only for settings that can be updated (both reading and writing require manage_options capability). See also #38731.

[jnylen0]

currently we intend the settings endpoint to be used only for settings that can be updated

My mistake about this part - sitting next to @jshreve and he pointed out that this is possible to update via wp-admin.

This ticket also made me think of the general need to expose gmt_offset and other data to API clients that may not have manage_options capability. For Quick Draft this is currently done via wp_localize_script which isn't a great solution (https://core.trac.wordpress.org/ticket/38342#comment:48).

[rmccue]

Replying to jnylen0:

currently we intend the settings endpoint to be used only for settings that can be updated

My mistake about this part - sitting next to @jshreve and he pointed out that this is possible to update via wp-admin.

gmt_offset is actually a bit of a strange setting; it can either be set (the manual timezone offsets in the timezone dropdown), or derived from the actual timezone. Likely, the settings endpoint should expose the raw value (either unset or the manual timezone offset), and the site info can expose the derived value (which will always have a value).

[pento]

We can chat about this a bit more, but it doesn't need to be in 4.7.

[dd32]

I'm marking this as needs-patch, as it sounds like the approach in gmt_offset_rest_api.diff​ isn't complete for what we should be doing here.

[jnylen0]

gmt_offset and timezone_string are weird. I'd like to see this weirdness abstracted out of the API so that you can set and read either one any time that operation would make sense.

This isn't going to make it into 4.7.1 though.

[jnylen0]

Punting to 4.8 due to inactivity.

[flixos90]

Punting further due to inactivity.

[nickylimjj]

Replying to rmccue:

Replying to jnylen0:

currently we intend the settings endpoint to be used only for settings that can be updated

My mistake about this part - sitting next to @jshreve and he pointed out that this is possible to update via wp-admin.

Likely, the settings endpoint should expose the raw value (either unset or the manual timezone offset), and the site info can expose the derived value (which will always have a value).

I am picking this up. Could you @rmccue elaborate more on this? I am envisioning the interaction to be with settings endpoint to get the timezone and the posts endpoint to get the date_gmt, and calculating the local time_posted from there. Is this right?

[TimothyBlynJacobs]

@nickylimjj It looks like the values themselves were added to the site info endpoint in #39854. So the most straightforward solution would be to register the setting in register_initial_settings().

However, that wouldn't solve the weirdness that @jnylen0 mentioned. Perhaps @rarst has some thoughts on this with the current date-time improvements going on in core?

[Rarst]

From the perspective of Date/Time component: absolutely do not add more gmt_offset operations. Among many things it doesn't account for summer time (!) when based on timezone_string. We have some huge pending fixes for that at the moment.

You do not want to ever have to use gmt_offset for anything and it's very unfortunate that we are not in practical position to drop it (or even further discourage) altogether.

[kadamwhite]

@Rarst Thanks for chiming in! Based on that feedback, would you recommend we close this as wontfix?

[kadamwhite]

(Also relevant: GMT Offset is available read-only in the root / Rest API route response (or /wp-json/, with pretty permalinks). See #39854

[Rarst]

Replying to kadamwhite:

@Rarst Thanks for chiming in! Based on that feedback, would you recommend we close this as wontfix?

Probably. I mean if someone really needs it, they can always extend the API, right? So for general case it definitely should not be encouraged.

[TimothyBlynJacobs]

Closing based on @Rarst's comment.