discourage the setting of the offset in the options and that way always have a timezone string in options

[pbearne]

We have code that only runs/works if the timezone option is set so we should remove the ability to set just an offset by

1. removing them
2. or mapping them to a "default timezone"

related #29205

[SergeyBiryukov]

Related: #10660, #18146.

[swissspidy]

Yeah, we discussed this in #18146 and the consensus there was we couldn't just remove the manual GMT offset for BC reasons.

Mapping to a default timezone (including an upgrade routine) could work, though it may confuse users suddenly being in the "wrong" timezone.

[stephenharris]

I've tried (2) before - and it doesn't really work, largely because of DST. Also - what do you map it to? Does WordPress core decide? What if a timezone changes in between releases (edge case, I know).

I think (1) could work, so long as we keep the currently selected version (so as to ensure updating the settings page doesn't change their settings without them opting to change to a string timezone).

Then, the only loss of functionality is if you switch from an offset, you can't switch back to an offset.

As a third option: remove them only for new installs.

[pbearne]

I like the idea of removing if not set over time it clean it up

Maybe a filter to allow keeping the offsets

We could add an optgroup called deprecated (if I spelled that right ) in place of the manual offsets and only show a selected UTC ( UTC+0 is the default ) so this could be need still an option

Throughts?

Paul

[pbearne]

proposed patch

[pbearne]

Hi Guys

here is a patch for this

If a UTC offset is set then the UTC options are shown. But if a timezone string is set then the UTC options are hidden.

This behavior can be overridden with a new filter "show_utc_offsets" set to true to show and false to hide.

An unittest is included in patch

Thoughts and Comments

Paul

[pbearne]

Related: #29205

[pbearne]

#37465 was marked as a duplicate.

[pbearne]

Note this comment about Moscow Time https://core.trac.wordpress.org/ticket/18146#comment:15

[pbearne]

Related #28636

[Rarst]

We are on the verge of finally eliminating the impact of old timezone system on the code side with unified retrieval in #24730

With a clear path forward there I feel more reinforced that messing with this on user side of things is highly not worth it. This is an ancient setting, used on unknown amount of sites, for unknown number of reasons.

Proactively changing this workflow will introduce user confusion either proactively (prompting configuration change) or implicitly (different sites will have different availability of this setting and varied configuration experience).

Since we have a plan to deal with a code implications, I say let's just be careful and leave this alone on the user side.

PS If WordPress ever does backwards-incompatible release I will be first in line to scrape gmt_offset out of core entirely though... :)