Posted on by

Date Shifting and Other Timezone-related Issues in Participants Database

I problem I occasionally see with Participants Database is dates that are entered end up being saved as 1 day later or earlier. This problem and it’s solution is a little bit complicated, so I’ll take a minute to explain how this happens.

The basic reason for the problem has to do with timezone setting differences between the server, PHP, and WordPress. If you save a date, and that date gets stored to the database with an incorrect timezone, the date can shift, depending on the time of day and the difference between the WordPress timezone setting and the server timezone. It’s like if you call a friend that is several thousand miles to the East in the morning, you’ll probably both be in the same day…but if you call that same friend in the evening, the date for them will be one day later. The reverse is true if your friend is several thousand miles to the West.

Dates in Participants Database are saved as Unix Timestamps as though the time was UTC 00:00 (or 12:01am GMT) because it doesn’t save the time of day. This isn’t a problem as long as the timezone conversion is correct, but if there is an inconsistency in the timezone somewhere in the data process, a date shift can happen. I’ll explain why that happens, because that gives us the solution. It is necessary that this be a bit technical.

The way PHP handles timezones is that it uses a setting called “date.timezone’ to know which timezone to use. This setting is usually in the main PHP configuration file, but it can be in a local configuration file as well. The timezone setting can also be in a PHP script, and this is how WordPress sets the timezone using the WordPress timezone setting.

Depending on how the hosting server is set up, local configuration settings are not always inherited by scripts in other contexts. In other words, it’s possible to have the timezone set in WordPress, but for that setting to not be used by other scripts (such as plugins) because the server is not set up to propagate the local setting into all child directories.

The key to the problem is this: when PHP doesn’t know which timezone to use, it defaults to the server timezone. It is not uncommon for hosting servers to be set up so there is no base PHP timezone setting, so if the local setting isn’t active in a particular script, that script will end up using the server timezone.

The solution is generally to set the PHP timezone to the correct timezone, and to make sure that that setting is active in all directories. This may require contacting your web host about the issue, there is often a setting that will allow the local timezone setting to be inherited in all child directories. This will usually solve the problem.

Preventing the Plugin Timezone Sync

Still, this strategy manages to cause problems on some sites, so for that reason, it’s possible to override this with a filter:

add_filter( 'pdb-php_timezone_sync', function () { return false; } );

19 thoughts on “Date Shifting and Other Timezone-related Issues in Participants Database

  1. Thanks Roland, I just copied and pasted

    “add_filter( ‘pdb-timezone_assertion’, ‘alter_pdb_timezone_assertion’ ); function alter_pdb_timezone_assertion( $timezone ) { return $your_timezone; }”

    from above and it seemed to fix the issue.

    not sure what you were referring to about “but the question of what timezone value to use, you’ll have to figure that out”

    1. This is referring to the fact that even though the plugin uses the WordPress timezone, sometimes people want it to work differently, so it’s really just so people know they may need to use different values.

    2. So in that code, you are supposed to replace $your_timezone with the timezone you want to use. As it is, that has no value, so you are effectively setting the value to nothing.

  2. HI, Yes, it was time-shifting when PD was activated. I discovered a fix just now – changing timezone in WP to “UTC+10” instead of “Melbourne” fixed it, although I notice this is the opposite advice given to a previous reply. Either way, I’m happy it’s now working as it should and not messing up my WP site. Thanks.

    1. Thanks for letting us know what worked, Hugh.

  3. Great plugin! We’re really enjoying it. But I have a question. Is there a way I can use “pdb_total filter=” to bring results only for the current month? Please let me know. This will really help us out.

    1. It is possible, but you need to use a bit of code to accomplish it. Take a look at this tutorial:

      Showing results from a dynamic timeframe in Participants Database

  4. Sorry to be dense, but I’m not a programmer, so I need to know where to add the filter code you supplied above. Does it get added to one of the plugin’s files, such as participants-database.php perhaps? Thanks for your patience.

    1. You can put that in your theme functions file, but you’ll still need to figure out what values to use to solve the problem.

      Have you tried changing the WP timezone to match the timezone you want your dates to use?

      1. Thanks. Yes, our WP timezone is set to “Phoenix” but when I activate “Participants Database,” the timezone and local time values change, throwing off all sort of things. I have a site developer who can help me implement your suggestion.

      2. Hi,
        re: “but you’ll still need to figure out what values to use to solve the problem.”

        where do the values need to be taken from and input to? Sorry if this is a dumb question!

        1. What exactly is the problem? Is this about timezone shift?

        2. HI, Yes, this is about timezone shift. I eventually figured out a fix just now – changing timezone in WordPress to “UTC+10” rather than “Melbourne” fixed it and all is now working OK. When it was set to Melbourne, WP was shifting both the UTC time and the Melbourne time by 10 hours when PD plugin was activated. Thanks.

  5. We were planning on using the Participants Database, but on our installation (hosted at WP Engine), we discovered that the plugin appeared to be causing time-stamp havoc when our WP setting was “Phoenix” but behaved when we changed to “UTC-7.” When using Phoenix (which is what we prefer), the Participants Database was apparently altering both the “universal time” and “local time” values of our WordPress installation, shifting them 7 hours, while it shouldn’t have been touching those. This was discovered by copying our site to a test installation and disabling all other plugins. We’ve had to disable the plugin for now. I’m perusing the forum at https://wordpress.org/support/plugin/participants-database/ but haven’t yet found other reports of this happening.

    1. The plugin does set the PHP timezone in order to get consistent dates in the common situation where the WP timezone is dropped in some contexts, letting the server timezone take effect. What it does is use the date_default_timezone_set() function to set PHP to the current WP timezone. It is possible to alter this behavior using the ‘pdb-timezone_assertion’ filter which passes in the timezone value to use in that function.

      It’s not a great solution, but it was the best I could come up with and it has eliminated a major source of support requests.

      1. Thanks. How do I apply that solution? (the pdb-timezone_assertion filter)

        1. It’s just like any other WP filter, you set up a callback that returns the altered value.

          add_filter( 'pdb-timezone_assertion', 'alter_pdb_timezone_assertion' ); function alter_pdb_timezone_assertion( $timezone ) { return $your_timezone; }

          That is the how, pretty simple, but the question of what timezone value to use, you’ll have to figure that out. As it is now, it uses the WP timezone and that works great in most installations.

  6. I moved my site from between accounts of the same host, and my plugin is producing unexpected errors:
    Notice: date_default_timezone_set(): Timezone ID ” is invalid in /hermes/bosnaweb20a/…/wp-content/plugins/participants-database/classes/PDb_Base.class.php on line 497

    Could you please help me resolve this issue

    1. Check your WordPress timezone setting. Don’t use UTF +0, choose a city in your timezone from the list.

Leave a Reply
You have to agree to the comment policy.

19 thoughts on “Date Shifting and Other Timezone-related Issues in Participants Database

  1. Thanks Roland, I just copied and pasted

    “add_filter( ‘pdb-timezone_assertion’, ‘alter_pdb_timezone_assertion’ ); function alter_pdb_timezone_assertion( $timezone ) { return $your_timezone; }”

    from above and it seemed to fix the issue.

    not sure what you were referring to about “but the question of what timezone value to use, you’ll have to figure that out”

    1. This is referring to the fact that even though the plugin uses the WordPress timezone, sometimes people want it to work differently, so it’s really just so people know they may need to use different values.

    2. So in that code, you are supposed to replace $your_timezone with the timezone you want to use. As it is, that has no value, so you are effectively setting the value to nothing.

  2. HI, Yes, it was time-shifting when PD was activated. I discovered a fix just now – changing timezone in WP to “UTC+10” instead of “Melbourne” fixed it, although I notice this is the opposite advice given to a previous reply. Either way, I’m happy it’s now working as it should and not messing up my WP site. Thanks.

    1. Thanks for letting us know what worked, Hugh.

  3. Great plugin! We’re really enjoying it. But I have a question. Is there a way I can use “pdb_total filter=” to bring results only for the current month? Please let me know. This will really help us out.

    1. It is possible, but you need to use a bit of code to accomplish it. Take a look at this tutorial:

      Showing results from a dynamic timeframe in Participants Database

  4. Sorry to be dense, but I’m not a programmer, so I need to know where to add the filter code you supplied above. Does it get added to one of the plugin’s files, such as participants-database.php perhaps? Thanks for your patience.

    1. You can put that in your theme functions file, but you’ll still need to figure out what values to use to solve the problem.

      Have you tried changing the WP timezone to match the timezone you want your dates to use?

      1. Thanks. Yes, our WP timezone is set to “Phoenix” but when I activate “Participants Database,” the timezone and local time values change, throwing off all sort of things. I have a site developer who can help me implement your suggestion.

      2. Hi,
        re: “but you’ll still need to figure out what values to use to solve the problem.”

        where do the values need to be taken from and input to? Sorry if this is a dumb question!

        1. What exactly is the problem? Is this about timezone shift?

        2. HI, Yes, this is about timezone shift. I eventually figured out a fix just now – changing timezone in WordPress to “UTC+10” rather than “Melbourne” fixed it and all is now working OK. When it was set to Melbourne, WP was shifting both the UTC time and the Melbourne time by 10 hours when PD plugin was activated. Thanks.

  5. We were planning on using the Participants Database, but on our installation (hosted at WP Engine), we discovered that the plugin appeared to be causing time-stamp havoc when our WP setting was “Phoenix” but behaved when we changed to “UTC-7.” When using Phoenix (which is what we prefer), the Participants Database was apparently altering both the “universal time” and “local time” values of our WordPress installation, shifting them 7 hours, while it shouldn’t have been touching those. This was discovered by copying our site to a test installation and disabling all other plugins. We’ve had to disable the plugin for now. I’m perusing the forum at https://wordpress.org/support/plugin/participants-database/ but haven’t yet found other reports of this happening.

    1. The plugin does set the PHP timezone in order to get consistent dates in the common situation where the WP timezone is dropped in some contexts, letting the server timezone take effect. What it does is use the date_default_timezone_set() function to set PHP to the current WP timezone. It is possible to alter this behavior using the ‘pdb-timezone_assertion’ filter which passes in the timezone value to use in that function.

      It’s not a great solution, but it was the best I could come up with and it has eliminated a major source of support requests.

      1. Thanks. How do I apply that solution? (the pdb-timezone_assertion filter)

        1. It’s just like any other WP filter, you set up a callback that returns the altered value.

          add_filter( 'pdb-timezone_assertion', 'alter_pdb_timezone_assertion' ); function alter_pdb_timezone_assertion( $timezone ) { return $your_timezone; }

          That is the how, pretty simple, but the question of what timezone value to use, you’ll have to figure that out. As it is now, it uses the WP timezone and that works great in most installations.

  6. I moved my site from between accounts of the same host, and my plugin is producing unexpected errors:
    Notice: date_default_timezone_set(): Timezone ID ” is invalid in /hermes/bosnaweb20a/…/wp-content/plugins/participants-database/classes/PDb_Base.class.php on line 497

    Could you please help me resolve this issue

    1. Check your WordPress timezone setting. Don’t use UTF +0, choose a city in your timezone from the list.

Leave a Reply
You have to agree to the comment policy.