timezone reset

[bl968]

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

[ryan]

What version of WP were you upgrading from?

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

[bl968]

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

[ryan]

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.

[miqrogroove]

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?

[miqrogroove]

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

[ryan]

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.

[ryan]

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.

[miqrogroove]

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

[ryan]

Indeed.

bl968, what version of PHP are you running?

[miqrogroove]

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

[bl968]

PHP: 5.2.0-8+etch16 (cli) (built: Nov 24 2009 11:14:47)
Mysql:5.0.32-Debian_7etch11-log
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.

[miqrogroove]

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

[bl968]

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

[azaozz]

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.

[miqrogroove]

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

[ryan]

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

[miqrogroove]

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

[miqrogroove]

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

[ryan]

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.

[ryan]

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.

[ryan]

[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.

[ryan]

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.

[ryan]

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') )
	date_default_timezone_set('UTC');

[miqrogroove]

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

[ryan]

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.

[ryan]

Don't use Etc zones

[ryan]

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.

[bl968]

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.

[ryan]

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.

[miqrogroove]

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.

[miqrogroove]

ryan's patch fixed at line 119

[miqrogroove]

Fixed.

[automattor]

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

[ryan]

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