Default timezone should be set for PHP5

[Viper007Bond]

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

[dd32]

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

[scribu]

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

[dd32]

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

[jacobsantos]

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.

[jacobsantos]

This is probably a duplicate.

[Denis-de-Bernardy]

Replying to jacobsantos:

This is probably a duplicate.

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

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

[Denis-de-Bernardy]

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

[janeforshort]

Punting due to beta status.

[Denis-de-Bernardy]

this is a trivial patch, and a blocker imo.

[dd32]

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?

[Denis-de-Bernardy]

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.

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

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.

[Denis-de-Bernardy]

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.

[westi]

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?

[Denis-de-Bernardy]

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.

[ryan]

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

[ryan]

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

[Otto42]

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.

[eitch]

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

[eitch]

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.

[Otto42]

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.