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()".

This was introduced in #10940.

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.

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.

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.

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.

See #10940 for history behind the timezone set call.

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()?

See also #11672.

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

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.

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

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

very true, sorry 'bout that.

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.

[12727]