Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#11665 closed defect (bug) (fixed)

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

Reported by: iacas Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9
Component: Date/Time Keywords: has-patch needs-testing
Focuses: Cc:


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:

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

Attachments (3)

wp-settings.php.diff (360 bytes) - added by sirzooro 7 years ago.
11665.diff (437 bytes) - added by Denis-de-Bernardy 7 years ago.
11665.2.diff (918 bytes) - added by ryan 7 years ago.

Download all attachments as: .zip

Change History (18)

#1 @sirzooro
7 years ago

  • Keywords needs-patch added; utc time_zone removed
  • Milestone changed from Unassigned to 2.9.1

This was introduced in #10940.

#2 @sirzooro
7 years ago

  • Keywords has-patch needs-testing added; needs-patch removed

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.

#3 @Denis-de-Bernardy
7 years ago

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.

#4 @Denis-de-Bernardy
7 years ago

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.

#5 @ryan
7 years ago

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.

7 years ago

#6 @ryan
7 years ago

See #10940 for history behind the timezone set call.

#7 @ryan
7 years ago

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

#8 @ryan
7 years ago

See also #11672.

#9 @ryan
7 years ago

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

#10 @Denis-de-Bernardy
7 years ago

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.

#11 @Denis-de-Bernardy
7 years ago

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

#12 @ryan
7 years ago

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

#13 @Denis-de-Bernardy
7 years ago

very true, sorry 'bout that.

#14 @ryan
7 years ago

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.

#15 @ryan
7 years ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.