UTC Time Zone Set in wp-settings affects items in header

[iacas]

The wp-settings.php file in WordPress 2.9 sets time zone to UTC, which is then not set to the user-specified time zone (via the wp-admin settings) until just after get_header().

This causes problems for items which use the date and/or time in the header file, as my random header rotator does:
​http://nslog.com/2009/12/24/wordpress_29_when_is_time_zone_set

I think that if wp-settings is going to continue to set the time zone to UTC by default (around line 21), then the proper, user-specified time zone should be set earlier than "at the end of get_header()".

[sirzooro]

This was introduced in #10940.

[sirzooro]

Attached patch should do the trick.

From PHP documentation for date_default_timezone_get():

In order of preference, this function returns the default timezone by:

• Reading the timezone set using the date_default_timezone_set() function (if any)
  
• Reading the TZ environment variable (if non empty)
  
• Reading the value of the date.timezone ini option (if set)
  
• Querying the host operating system (if supported and allowed by the OS)
  
• If none of the above succeed, date_default_timezone_get will return a default timezone of UTC.

[Denis-de-Bernardy]

I get:

Warning: date_default_timezone_get() [function.date-default-timezone-get]: It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.

[Denis-de-Bernardy]

this seems to work, however, and it might be better than the current code:

date_default_timezone_set(ini_get('date.timezone') ? ini_get('date.timezone') : 'UTC');

it might fix the follow-up calendar bug that is only partially fixed, too.

[ryan]

date.timezone is often not set. Should me move calling date_default_timezone_set() further down in wp-settings.php so we can use the timezone_string option, if set? That way it will be set before init instead of getting set the first time something tries to reference gmt_offset.

[ryan]

See #10940 for history behind the timezone set call.

[ryan]

Won't changing this reopen #9588? Do we need to force UTC as the default timezone and avoid setting the default in wp_timezone_override_offset()?

[ryan]

See also #11672.

[ryan]

We may need to wait until 3.0 and clean up #9588, #11672, #10915, and this one all at once.

[Denis-de-Bernardy]

11665.2.diff won't work because of the pre_option_ filter on it, and that filter generates the above-mentioned warning on servers that use time functions without a date.timezone setting.

The correct patch, I think, is 11665.diff. But we'd ideally like to make sure that it fixes #11672 and the like as well.

[Denis-de-Bernardy]

And yes; using date.timezone will re-introduce #9588 indeed.

[ryan]

I thought the pre_option was only on gmt_offset, not timezone_string.

[Denis-de-Bernardy]

very true, sorry 'bout that.

[ryan]

Calling date() without passing current_time() when wanting the blog's local time is not portable across all the versions of PHP WP supports. The fact that it kinda/sorta worked for 2.8 on recent versions of PHP5 was pretty much an accident. :-) current_time() itself needs some fixing (see #11672 and #9588), but fixing it so that it works reliably across all supported environments may mean forcing the timezone to UTC and requiring the use of current_time() when you want to get the blog's time.

[ryan]

[12727]