WordPress.org

Ready to get started?Download WordPress

Forums

Why does wordpress set timezone to UTC? (5 posts)

  1. rpickett
    Member
    Posted 1 year ago #

    This is a pretty frustrating issue for plugin development.

    1. The server is set to America/Chicago.
    2. php.ini sets the TZ to America/Chicago.
    3. WordPress -> Settings -> General -> Timezone is set to America/Chicago.

    A simple plugin that takes a user-input Y-m-d H:i:s date/time and then displays it somehow always ends up in UTC.

    Why? Because wp-settings.php sets the timezone to UTC.

    So anytime your plugin code is going to do anything with date/time you always have to call date_default_timezone_set( get_option( 'timezone_string' ) ) first.

    I don't want to start a religious war, I just want to understand why WP would give the blog admin the ability to set a timezone in the settings and then force UTC anyway. The reasoning escapes me.

    Thanks for all your great explanations!

  2. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    This is mostly a holdover from when WordPress supported PHP 4.

    PHP 4 didn't have a way to set timezones like that, and so do timezone related calculations. In order to work around this, WordPress implemented its own time calculation code.

    Originally, the timezone setting was limited to selecting +1 hours, +2 hours, etc. It was annoying and you had to change it twice a year for daylight savings time.

    So 4 years ago, around WordPress 2.8 or so, I wrote the patch that added the new method of choosing timezone. If PHP 5 was on the server, it would get the timezone information from PHP and then apply the calculations automatically to handle daylight savings. This is where the timezone_string came from.

    However, because PHP 4 was still being supported, the old code for calculating timezone was retained, and to make all WordPress instances behave identically, the default timezone was set to UTC. My first patch actually did set the date_default correctly, but this caused strange and inconsistent behavior because much of the core assumed UTC for date() calls and the like.

    This may be fixed in the future, but it's a big job. Lots of code to deal with and adjust to the new way of doing things. It's not a priority though, because it works for now. However, it is a bit of a minor performance hit (see http://core.trac.wordpress.org/ticket/23132), so that might affect things.

    Note that you should not call date_default_timezone_set to change the timezone, because much of the core still assumes UTC when doing calculations. This can affect things like scheduling of posts and cause other strange behavior.

    Instead, you should use the functions in WordPress to retrieve times, such as current_time, for example. Alternatively, if you do change the date default, make sure to change it back to what it was before after you're done.

  3. rpickett
    Member
    Posted 1 year ago #

    Thanks for your thorough explanation. I figured it was some hold-over from years gone by.

    My current method is to get the current timezone with date_default_timezone_get and then set it back before my function exits.

    According to your explanation, that's always going to be UTC thought, right? ;-D

    At least until it's decided to gut the timezone code and do it the "right" way.

    Thanks again!

  4. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    I would not assume that it's always going to be UTC... What if we change this in the future to be right? :)

    Do a date_default_timezone_get() to save the current setting, do your calculations, then change it back to that saved setting.

  5. Samuel Wood (Otto)
    Tech Ninja
    Posted 1 year ago #

    Also note that it could be worse. In some Facebook API calls, the timezone is implicitly assumed to be California. Seriously. No warning. No way to change it. Not documented. Fun times I had figuring that one out.

Topic Closed

This topic has been closed to new replies.

About this Topic