Date miscalculation with string timezone after moving server

  • Resolved te-online

    (@thomasebert)


    8 years, 11 months ago

    Hello!

    I’m stuck with a timezone issue and don’t know how to debug it any further.

    I moved to another host earlier with more than 10 WordPress sites and each of them show the same behaviour. All of them are up-to-date to the newest version and the newest plugin versions. The server uses PHP 7.0.4, but I set it to 5.6.19 as well with no effect on the problem.

    Expected behaviour:
    – Timezone in WordPress settings is set to ”Berlin“ (which is the correct location)
    – Time is shown correctly when creating posts and pages
    – Posts and pages are published immediately when hitting ”Publish“
    – Server timezone can safely be set to UTC

    Actual behaviour:
    – Posts and pages show as ”planned“ when I hit ”Publish“, planned for the exact same time the clock shows right now
    – Posts and pages will be published one hour after actual publishing
    – Setting the timezone in WordPress settings to UTC+2 (or UTC+1 with ”standard time“) fixes the issue completely
    – Setting the server’s timezone to ”Europe/Berlin“ (like it used to be on my old host) has no effect whatsoever

    I appreciate any ideas about what I could do to debug this any further or which changes I could ask my host for to make it work with timezone strings again.

    Thanks
    Thomas

    I’ve added screenshots of the date settings.

    PHP date settings on old host:
    https://te-cloud.de/index.php/s/NRzCUzELybU5Qet

    PHP date settings on new host, before I asked to change it:
    https://te-cloud.de/index.php/s/tWJhEKASLLutrBB

    PHP date settings on new host, after changing it with no effect on the issue:
    https://te-cloud.de/index.php/s/yZMxweQ3EnMspKt

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter te-online

    (@thomasebert)

    Okay, I explored this a bit further and want to update this thread for documentation and also to ask for help once again.

    The main issue seems to be that when the timezone is set to a string (like ”Berlin“) in the settings, the post_date_gmt will be set to the same time as post_date which is not gmt in this case obviously. This is only true for the main post. The revisions strangely have the correct post_date_gmt.

    When the timezone is set to UTC+2 in the settings, everything works as expected. The post_date_gmt will be set to two hours earlier than post_date. This would be the expected behaviour for the string setting as well.

    I’ve seen this behaviour only on this configuration, but can’t find the failure or even the difference to another machine that is configured similarly.

    I’m still hoping somebody with a lot of ”server experience“ could have a hint for me, where to look for a solution. ??

    –– Thomas

    Moderator Samuel Wood (Otto)

    (@otto42)

    www.ads-software.com Admin

    WordPress does not care what the default PHP timezone is, so that setting makes zero difference. WordPress always sets the “default” timezone to UTC. Your server should also be set to UTC on the server time.

    Also note that the server *date* is actually important here, because the timezone code in PHP takes DST into account when you’re using a named zone such as Europe/Berlin.

    The long and the short of it is as follows:
    – Check the server date and time. Make sure those are correct and UTC.
    – PHP’s own default timezone settings don’t matter.
    – Make sure you’re using the latest version of PHP available to you on the hosting service. These are more likely to be up-to-date and to have the latest Olson timezone database.

    Basically, it sounds like your server itself is not set to UTC time. PHP kind of assumes that’s what the server is. If the server is set wrong, then all calculations stemming from that will be off as well.

    BTW, you keep saying just “Berlin” for the WordPress timezone setting, but it’s “Europe/Berlin”. That’s what should be set and in the database’s timezone_string field. If you are somehow setting it to literally just “Berlin”, then that’s wrong. “Berlin” is not a timezone. “Europe/Berlin” is. Shockingly, this actually matters. While we display it nice and organized in the drop down list, the database needs to have that exact string in it.

    Thread Starter te-online

    (@thomasebert)

    Thanks a lot for your answer!
    I started to check back with my hosting provider, I’ll give them your info and report on the outcome.

    –– Thomas

    Thread Starter te-online

    (@thomasebert)

    Okay, the solution to this was really simple. My hosting provider reinstalled/upgraded the package tzdata and everything works fine now! ??

    –– Thomas

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Date miscalculation with string timezone after moving server’ is closed to new replies.