Make WordPress Core

Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#11558 closed defect (bug) (fixed)

timezone reset

Reported by: bl968's profile bl968 Owned by:
Milestone: 2.9.1 Priority: normal
Severity: major Version: 2.9
Component: Date/Time Keywords: timezone, reset, default value
Focuses: Cc:


The timezone for my Wordpress installation was reset to Abidjan sometime during or after the upgrade to Wordpress 2.9. Verified this occurred on three independent Wordpress installations. I noticed when I scheduled a post to come up at 05:00 today and it showed up as already posted on my site at 01:00.

Also the process for selecting a timezone in the admin panel could use some serious work. I had to select about 10 cities before I found a one in the timezone I am located in (CST, Nashville, TN). Ended up selecting Knox, IN. Shouldn't have to hunt and guess...

Break up list by country, or GMT offset; not by continent. Also give a option to select by standard timezones for United States EST, CST, MST, PST...

Attachments (3)

wp-includes-functions-phpdoc.diff (3.1 KB) - added by miqrogroove 15 years ago.
phpdoc for @since 2.8 and @since 2.9 in wp-admin/functions.php
11558.diff (5.6 KB) - added by ryan 15 years ago.
Don't use Etc zones
11558.2.diff (5.6 KB) - added by miqrogroove 15 years ago.
ryan's patch fixed at line 119

Download all attachments as: .zip

Change History (34)

#1 @ryan
15 years ago

What version of WP were you upgrading from?

Yes, the selection UI is really bad. Revising it is on the todo.

#2 @bl968
15 years ago

2.8.5 on all three. These are production sites and so we stick to the general releases.

#3 @ryan
15 years ago

2.9 upgrade doesn't touch the timezone options at all if coming from 2.8.*. If it's showing "Abidjan" then the timezone_string option in the database is probably empty. We need to fix that display issue so that it shows gmt_offset if timezone_string is not set. I notice during scratch installs we set timezone_string to an empty string, resulting in "Abidjan" being displayed. That needs to be fixed. Anyhow, still looking into the problem.

#4 @miqrogroove
15 years ago

Break up list by country, or GMT offset;

GMT offsets should be listed already at the bottom of the list. Do you see those in there now?

#5 @miqrogroove
15 years ago

Actually, I take that back. The "Custom Offsets" are limited to whole hours, making them useless in many countries.

#6 @ryan
15 years ago

timezone_identifiers_list() in my PHP 5.3 doesn't return 'Etc' timezones which are used to display UTC offsets. WP maps gmt_offset to Etc zones when timezone_string is not set. Since there are no Etc zones being returned from timezone_identifiers_list, the dropdown doesn't have the correct zone set as default and Abidjan ends up being displayed since it is first in the list.

#7 @ryan
15 years ago

This shouldn't affect how the current time is computed elsewhere in WP, however. If timezone_string is not set (which it isn't until someone explicitly sets it in the dropdown), gmt_offset is used. gmt_offset is what is set during install and what is used for upgraded blogs. The display issue in options-general.php is just that, a display issue, as far as I can tell. If your timezone_string was actually set to something before upgrade, then that is a different problem.

#8 @miqrogroove
15 years ago

It's not a "display issue" if any of the other settings on that page need to be changed by the user :/

#9 @ryan
15 years ago


bl968, what version of PHP are you running?

#10 @miqrogroove
15 years ago

On a bit of a tangent, I couldn't find a shred of documentation for wp_timezone_choice(). Which file is it in?

#11 @bl968
15 years ago

PHP: 5.2.0-8+etch16 (cli) (built: Nov 24 2009 11:14:47)
Apache Server: Apache/2.2.3 (Debian) mod_python/3.2.10 Python/2.4.4 PHP/5.2.0-8+etch16 mod_perl/2.0.2 Perl/v5.8.8

All I can tell you is that I did not notice the issue before the upgrade to Wordpres 2.9. I post on average 4 articles per day.

#12 @miqrogroove
15 years ago

Ah, found it in blame. If anyone else is looking it's at [10753]

#13 @bl968
15 years ago

The problem with the UTC offsets is that they disable the automatic Daylight Savings Time change which is a problem.

#14 @azaozz
15 years ago

It seems that we need at least three different versions of that: PHP 4, PHP 5.0-5.2 and PHP 5.3+. Also the (very) big list of cities makes it harder to use in PHP 5+.

Perhaps we should break the drop-down in GMT offsets and list 2-3 of the largest cities that are in the same time zone under each (regardless of country/continent). IMHO that would make it less confusing. This would also make it look the same in PHP 4 and 5.

#15 @miqrogroove
15 years ago

Can I add phpdoc patches here or would you prefer a separate ticket?

#16 @ryan
15 years ago

azaozz, I'm working on a patch that eliminates reliance on Etc and puts our own manual offsets into the dropdown.

15 years ago

phpdoc for @since 2.8 and @since 2.9 in wp-admin/functions.php

#17 @miqrogroove
15 years ago

I'll take your silence to mean, "yes we want docs any way we can get them" ;)

#18 @ryan
15 years ago

bl968, did you visit options-general.php since upgrading and press save? This is a bug in 2.8 as well if you have a version of PHP that doesn't return the Etc zones, but if you never visited the options page and saved the display bug couldn't have caused into the bigger bug of having the wrong offset saved.

#19 @ryan
15 years ago

miqrogroove, since that patch involves functions other than the timezone ones, a separate ticket against 3.0 would be nice. We could slip phpdoc for the timezone ones into 2.9.1 since it seems we'll be making some substantial changes to those funcs to fix this issue.

#20 @ryan
15 years ago

[12315] introduced date_default_timezone_set() which seems to affect what timezone_identifiers_list() returns. So this is 2.9 specific in that regard, although 2.8 running on php setups that have a default timezone set in php.ini will also experience the problem.

#21 @ryan
15 years ago

Looks like calling that function or setting php.ini removes the deprecated zones in the Others group, including Etc. Removing reliance on Etc seems to be the way to go.

#22 @ryan
15 years ago

To summarize, if you have date.timezone set in php.ini, both 2.8 and 2.9 are broken. If you do not, then only 2.9 is broken since it calls date_default_timezone_set() to set the default zone. If you are running 2.9 and do not have date.timezone set in php.ini, you can workaround this problem by removing the following from wp-settings.php:

if ( function_exists('date_default_timezone_set') )

#23 @miqrogroove
15 years ago

Doesn't PHP5 throw all sorts of Warnings when those are missing?

#24 @ryan
15 years ago

It can, but it doesn't matter if display_errors is off. You're no worse off than in 2.8 where the default wasn't set.

15 years ago

Don't use Etc zones

#25 @ryan
15 years ago

Patch removes Etc from the list of zones. UTC and Manual Offset zones are added instead. gmt_offset is mapped to one of the manual offset when displaying the dropdown. When saving the options, the manual offset is mapped back to gmt_offset. If timezone_string in the DB is set to an Etc zone, timezone_string is set to an empty string so that we fallback to gmt_offset. We might also want to add some upgrade code that removes Etc zones when upgrading so that gmt_offset is used instead.

#26 @bl968
15 years ago

No I wouldn't have had any reason to change anything on the main settings page. I most likely did update sub-pages of the settings. Perhaps it set it then.

#27 @ryan
15 years ago

bl968, it turns out that 2.9 aggravates the problem, so my earlier comments about 2.8 and 2.9 being exactly the same were wrong. Sorry for the confusion.

#28 @miqrogroove
15 years ago

I applied the patch over my 2.9-RC1 files. Before patching, I had switched the timezone from UTC-5 to Detroit. After patching there were no errors, but there was one problem:

Switching the timezone from Detroit to UTC-5 caused the timezone menu to show Abidjan, and only "UTC time" is displayed next to it.

I can still switch to Detroit normally, and I can reproduce the problem by switching back to UTC-5 again.

15 years ago

ryan's patch fixed at line 119

#30 @automattor
15 years ago

  • Resolution set to fixed
  • Status changed from new to closed

(In [12507]) Do not use deprecated Etc timezones. Props miqrogroove. fixes #11558 for trunk

#31 @ryan
15 years ago

(In [12508]) Do not use deprecated Etc timezones. Props miqrogroove. fixes #11558 for 2.9

Note: See TracTickets for help on using tickets.