Remove the check if date_default_timezone_set() exists

[j-idris]

I am not sure why this logic exists but from the way I see it if the default timezone is set, overwrite the setting with "UTC" timezone. It doesn't make sense to me because I could have set a date.timezone setting in php.ini and I wish to use that setting instead of UTC. After the fix, all PHP date() calls return datetime values based on the timezone set in php.ini.

wp-settings.php Line 36

// Set default timezone in PHP 5.
if ( function_exists( 'date_default_timezone_set' ) )
	date_default_timezone_set( 'UTC' );

My fix:

// Set default timezone in PHP 5.
if ( !function_exists( 'date_default_timezone_set' ) )
	date_default_timezone_set( 'UTC' );

[dd32]

WordPress sets the defaulte timezone to UTC as it doesn't use the systems timezone, the majority of users are not located in the same timezone as their servers afterall, and relying on UTC as the core underlying timezone is the simplest option.

Instead, WordPress has a Timezone setting in the Options, which allows the time functions within WordPress to return a timezone which the user expects. As a result, all dates produced by WordPress will be in the timezone the user has specified, and not what their sysadmin set the servers timezone to. There will be cases where the PHP timezone will be set correctly, and the user hasn't set a proper timezone in WordPress, but this case is much more uncommon than the before mentioned.

(Also note, That code alteration is just asking for trouble, If not a function exists, call that function.. - A word to anyone who has this "problem" and tries to use that code to solve it, don't)

[duck_]

#10940 for the introduction of this call.

[j-idris]

Thanks for the clarification. I understand now why UTC is used. That being the case, why bother having the if statement at all. Why not just set UTC without checking for existence of the set function? It's irrelevant anyway.

This article clearly explains the reason behind this issue and how to get the correct timestamp based on the timezone string setting in the admin.

​http://codex.wordpress.org/Function_Reference/current_time

Replying to dd32:

WordPress sets the defaulte timezone to UTC as it doesn't use the systems timezone, the majority of users are not located in the same timezone as their servers afterall, and relying on UTC as the core underlying timezone is the simplest option.

Instead, WordPress has a Timezone setting in the Options, which allows the time functions within WordPress to return a timezone which the user expects. As a result, all dates produced by WordPress will be in the timezone the user has specified, and not what their sysadmin set the servers timezone to. There will be cases where the PHP timezone will be set correctly, and the user hasn't set a proper timezone in WordPress, but this case is much more uncommon than the before mentioned.

(Also note, That code alteration is just asking for trouble, If not a function exists, call that function.. - A word to anyone who has this "problem" and tries to use that code to solve it, don't)

[duck_]

Replying to j-idris:

Why not just set UTC without checking for existence of the set function?

The code was introduced before WordPress dropped support for PHP 4. The function didn't exist in PHP before version 5.1.0 and so older PHP installations would fatal error if the check wasn't there. Now that 5.2 is the minimum requirement that check can be dropped.

[bananastalktome]

(Removing keyword indicating the ticket as a candidate for closure)

[SergeyBiryukov]

In options-general.php, there's no check ([13702]):
​http://core.trac.wordpress.org/browser/tags/3.4.1/wp-admin/options-general.php#L184

wp_check_php_mysql_versions() runs earlier:
​http://core.trac.wordpress.org/browser/tags/3.4.1/wp-settings.php#L28

As far as I can see, there's no way to disable the DateTime class in PHP 5.2+ (unlike JSON, see #18015), so the patch seems good.

[nacin]

In [21544]:

We no longer need to check function_exists() for date_default_timezone_set(). props Gary-J, j-idris. fixes #20501.