Make WordPress Core

Opened 5 years ago

Closed 21 months ago

Last modified 16 months ago

#36591 closed defect (bug) (wontfix)

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

Reported by: pbearne Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Date/Time Keywords: has-patch dev-feedback has-unit-tests
Focuses: Cc:


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

Attachments (1)

wp_timezone_choice.patch (3.8 KB) - added by pbearne 5 years ago.
proposed patch

Download all attachments as: .zip

Change History (15)

#2 @swissspidy
5 years ago

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.

#3 @stephenharris
5 years ago

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.

#4 @pbearne
5 years ago

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



5 years ago

proposed patch

#5 @pbearne
5 years ago

  • Keywords has-patch dev-feedback has-unit-tests added

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


#6 @pbearne
5 years ago

Related: #29205

#7 @pbearne
5 years ago

#37465 was marked as a duplicate.

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

5 years ago

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

4 years ago

This ticket was mentioned in Slack in #core-datetime by pbearne. View the logs.

3 years ago

#13 @Rarst
21 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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... :)

This ticket was mentioned in Slack in #core-datetime by sergey. View the logs.

16 months ago

Note: See TracTickets for help on using tickets.