Make WordPress Core

Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#20501 closed enhancement (fixed)

Remove the check if date_default_timezone_set() exists

Reported by: j-idris's profile j-idris Owned by: nacin's profile nacin
Milestone: 3.5 Priority: normal
Severity: trivial Version: 3.3.1
Component: Date/Time Keywords: has-patch commit
Focuses: Cc:

Description

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' );

Attachments (1)

20501.diff (518 bytes) - added by GaryJ 12 years ago.

Download all attachments as: .zip

Change History (11)

#1 follow-up: @dd32
12 years ago

  • Keywords close added

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)

#2 @duck_
12 years ago

#10940 for the introduction of this call.

#3 in reply to: ↑ 1 ; follow-up: @j-idris
12 years ago

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)

#4 in reply to: ↑ 3 @duck_
12 years ago

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.

@GaryJ
12 years ago

#5 @GaryJ
12 years ago

  • Keywords has-patch added

#6 @bananastalktome
12 years ago

  • Keywords close removed

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

#7 @SergeyBiryukov
12 years ago

  • Keywords commit added
  • Severity changed from normal to trivial
  • Summary changed from Timezone bug in wp-settings.php to Remove the check if date_default_timezone_set() exists

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.

Last edited 12 years ago by SergeyBiryukov (previous) (diff)

#8 @SergeyBiryukov
12 years ago

  • Type changed from defect (bug) to enhancement

#9 @nacin
12 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [21544]:

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

#10 @SergeyBiryukov
12 years ago

  • Milestone changed from Awaiting Review to 3.5
Note: See TracTickets for help on using tickets.