WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#10940 closed defect (bug) (fixed)

Default timezone should be set for PHP5

Reported by: Viper007Bond Owned by:
Milestone: 2.9 Priority: high
Severity: critical Version: 2.9
Component: Date/Time Keywords: has-patch
Focuses: Cc:

Description

Related: #10533

WP_DEBUG is NOT enabled.

Multiple times per post:

Warning: strtotime() [function.strtotime]: 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. We selected 'America/Los_Angeles' for '-7.0/DST' instead in D:\Webserver\htdocs\wordpress-dev-embeds\wp-includes\functions.php on line 35

Warning: date() [function.date]: 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. We selected 'America/Los_Angeles' for '-7.0/DST' instead in D:\Webserver\htdocs\wordpress-dev-embeds\wp-includes\functions.php on line 43

Warning: date() [function.date]: 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. We selected 'America/Los_Angeles' for '-7.0/DST' instead in D:\Webserver\htdocs\wordpress-dev-embeds\wp-includes\functions.php on line 107

Warning: date() [function.date]: 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. We selected 'America/Los_Angeles' for '-7.0/DST' instead in D:\Webserver\htdocs\wordpress-dev-embeds\wp-includes\functions.php on line 109

Warning: date() [function.date]: 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. We selected 'America/Los_Angeles' for '-7.0/DST' instead in D:\Webserver\htdocs\wordpress-dev-embeds\wp-includes\functions.php on line 111

Warning: date() [function.date]: 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. We selected 'America/Los_Angeles' for '-7.0/DST' instead in D:\Webserver\htdocs\wordpress-dev-embeds\wp-includes\functions.php on line 112

Attachments (1)

10940.diff (410 bytes) - added by Denis-de-Bernardy 6 years ago.

Download all attachments as: .zip

Change History (23)

comment:1 @dd326 years ago

That happens when you upgrade through a few PHP versions and use old php.ini files, You neglect to update the new fields you need.

Set the 'date.timezone' php.ini setting correctly and PHP will not throw errors about its configuration every pageload which uses any date related functions.

tempted to close as invalid, However, WordPress could use that function and set a default timezone i guess.. but that really depends on the server..

comment:2 @scribu6 years ago

I've installed PHP 5.3 clean and I also got that error. So it's not because of old ini files.

comment:3 @dd326 years ago

I've installed PHP 5.3 clean and I also got that error. So it's not because of old ini files.

No, Old ini files are just one example of why new PHP settings may not be set correctly. This is one of the configuration settings that PHP needs setting when you first install. PHP no longer likes to rely on the System clock as the message shows..

comment:4 @jacobsantos6 years ago

  • Component changed from General to Date/Time
  • Milestone changed from 2.9 to Unassigned
  • Priority changed from normal to lowest
  • Resolution set to invalid
  • Severity changed from normal to trivial
  • Status changed from new to closed
  • Summary changed from date() and strtotime() warnings in PHP 5.3 to Default timezone should be set for PHP5
  • Type changed from defect (bug) to enhancement
  • Version 2.9 deleted

Closing as invalid for the following reasons:

  1. Which timezone do you prefer we set the timezone to? The problem is that quite a few time calls are made before the DB is loaded the timezone can be pulled. I do believe it is called and set later, but it is far to late for most of those errors.
  2. There are quite a few ways of setting this value. Not only in php.ini, but also in other places, check php.net for more.
  3. This should really, really be set in your php.ini file. If you are using shared hosting then ask your host to set it to where the timezone the server is hosted. This won't exactly help you, since many hosting won't be in the same timezone as you, but it will remove the error and the correct timezone will be set when WordPress starts to use the time calculations.
  4. This is a server/PHP issue, not a WordPress one. While it could be fixed, it will be an enhancement (nothing is technically broken, as it works for me, but only because I set the php.ini value and have the ability to do so).
  5. The workaround is to use the function and set it in your wp-config.php.

comment:5 follow-up: @jacobsantos6 years ago

This is probably a duplicate.

comment:6 in reply to: ↑ 5 @Denis-de-Bernardy6 years ago

Replying to jacobsantos:

This is probably a duplicate.

yeah... of: #9588, #8662, etc.

http://core.trac.wordpress.org/ticket/9588#comment:20

@Denis-de-Bernardy6 years ago

comment:7 @Denis-de-Bernardy6 years ago

  • Keywords has-patch added
  • Milestone changed from Unassigned to 2.9
  • Resolution invalid deleted
  • Status changed from closed to reopened

Re-opening this one with a patch, because the warnings are a genuine annoyance.

comment:8 @janeforshort6 years ago

  • Milestone changed from 2.9 to Future Release

Punting due to beta status.

comment:9 @Denis-de-Bernardy6 years ago

  • Milestone changed from Future Release to 2.9
  • Priority changed from lowest to high
  • Severity changed from trivial to critical

this is a trivial patch, and a blocker imo.

comment:10 @ryan6 years ago

  • Type changed from enhancement to defect (bug)

comment:11 @dd326 years ago

The problem with calling that function, is it sets it to an incorrect timezone.

You cant assume a server is running in UTC time. Eg, yours throws up "We selected 'America/Los_Angeles' for '-7.0/DST'".. Which if it were set to UTC, would cause incorrect times in calculations?

comment:12 @Denis-de-Bernardy6 years ago

Sure. But then again we make the assumption in WP (in current_time()) that time() returns UTC time indeed. The suggested patch actually enforces this.

With the patch applied, we close this ticket, as well as #9588, #8662, etc.

comment:13 follow-up: @dd326 years ago

  • Version set to 2.9

Sure. But then again we make the assumption in WP (in current_time()) that time() returns UTC time indeed. The suggested patch actually enforces this.

And in the case where servers have defined it correctly?

I'm all for closing this.. But i just think theres a reason why PHP doesnt default to UTC, because it knows this ISNT UTC time.

comment:14 in reply to: ↑ 13 @Denis-de-Bernardy6 years ago

Replying to dd32:

Sure. But then again we make the assumption in WP (in current_time()) that time() returns UTC time indeed. The suggested patch actually enforces this.

And in the case where servers have defined it correctly?

In this case, you get #9588, #8662, etc.

I'm all for closing this.. But i just think theres a reason why PHP doesnt default to UTC, because it knows this ISNT UTC time.

If we close, we'd do so on grounds it would only ever happen on poorly configured servers (such as, *cough*, localhost). But again, we then have the above two mentioned tickets, and more.

comment:15 follow-up: @westi6 years ago

What percentage of hosts currently support PHP5.3 and have it as the default and have this issue?

Also I don't see why we need to check the ini file.

We probably should just call this with UTC is the function is defined as we expect that to be the default timezone?

comment:16 in reply to: ↑ 15 @Denis-de-Bernardy6 years ago

Replying to westi:

What percentage of hosts currently support PHP5.3 and have it as the default and have this issue?

very small, based on php 5.3 usage -- I don't see much of it in my logs.

We probably should just call this with UTC is the function is defined as we expect that to be the default timezone?

my point entirely.... and we'd invalidate most of the tickets over in the date component by doing so.

comment:17 @ryan6 years ago

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

(In [12315]) Set default timezone. Props Denis-de-Bernardy. fixes #10940

comment:18 @ryan6 years ago

Removed the ini_get so that we always set the timezone if the function exists. Let's see how it goes.

comment:19 @Otto426 years ago

Note: Patching in this manner will result in different results with various time function calls between PHP5 and PHP4 setups. It will also result in different results for the output of a time() call at various points in WP execution.

Not that the patch is wrong (it's not), I'm just noting the fact for future reference.

This makes it important for everybody to remember the difference between gmtime() and time() and other similar functions anywhere else in WordPress.

If you want current UTC time, you must use gmtime() type functions. Normal time() functions are not guaranteed to give you any particular time settings, but will usually give you the adjusted local-time. The actual current local timezone won't get loaded until somebody tries to call wp_timezone_override_offset(), which happens pretty much anytime a WordPress time-related function gets called.

comment:20 @eitch5 years ago

I upgraded WordPress from 2.8.4a to 2.9.2 (MU) and began getting affected by this patch (on wp-settings.php). Before, when I created a new blog, the gmt_offset was set automatically based on my current server timezone (PHP 5.1, system timezone -3 and date.timezone configured too), now wp-settings.php override my timezone and by default gmt_offset blog option is created (function populate_options() in wp-admin/includes/schema.php) with UTC time by default.

This is an annoyance for me because every time a blog is created, the setting must be set to the correct gmt_offset. I checked 3.0 and it's still there.

Are there any solutions for this? I understood that the patch eliminates annoying warning messages on newer php versions and closes strange behaviors on other functions like time() and gmtime(), but are there any workarounds or smarter ways to do this? Maybe commenting the lines with date_default_timezone_set on wp-settings.php? Are there any drawbacks on this approach? :)

Or really, all user in a multi-user installation must always set the gmt_offset? :(

comment:21 @eitch5 years ago

Since I didn't get any feedback, I'm going to be stuck with setting gmt_offset everytime I create a new blog. IMHO it's better than changing wp-settings.php directly.

comment:22 @Otto425 years ago

eitch: Be patient with this one. WP 3.2 is going to drop support for PHP 4. Since the only reason for this odd fix is PHP 4 compatibility, it'll be possible to fix it properly after we're PHP 5 only.

Note: See TracTickets for help on using tickets.