A 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.
One thing to check if you’re seeing this problem is your WordPress timezone setting. Using a setting like “UTC -7” can lead to date shifting. Using setting of “San Francisco” instead will fix the problem.
Dates in Participants Database
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 in the plugins settings: under the “Advanced” tab, you can disable this by unchecking the “Sync php Timezone” preference.
Note: as of WordPress version 5.2 the “Health Check” page will show a warning if this setting is checked. If you uncheck this preference, the warning will go away, but you should test your site to make sure you’re not having problems with date shifting. The warning can be ignored if you need to use this setting.
Craig Steeland 
Roland Barker 
dominic loiacono 
Rameez Abid 
Peter
I have used Participants Database in the UK for years without any problems. However, very recently it has exhibited a lot of date related problems – dates out by one day, dates not saving, etc. I tried suggested solutions which have not worked, but have now found a fix after much trial and error with various settings.
Here are Original Settings:
WordPress Timezone: London
WordPress Date Format: d/m/Y
PD Strict Date Format: Checked
PD Input Date Format: dd/mm/yyyy
Sync php Timezone: Checked
Here Are the New Settings Which Fixed the Problems:
WordPress Timezone: UTC+0
WordPress Date Format: d/m/Y
PD Strict Date Format: Checked
PD Input Date Format: d/m/Y
Sync php Timezone: Checked
I am posting this in the event that this information may be of use to other PD users.
Thanks for this Craig, your findings suggest that the requirements for the WP timezone setting have changed, I did not know that.
As to the format string for the Participants Database strict date format, I’m going to have to look into that. Confusingly, php uses two different date formatting systems, I need to make sure that which one is the correct one to use is made clear.
Great, works perfectly!
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”
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.
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.
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.
Thanks for letting us know what worked, Hugh.
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.
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
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.
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?
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.
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!
What exactly is the problem? Is this about timezone shift?
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.
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.
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.
Thanks. How do I apply that solution? (the pdb-timezone_assertion filter)
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.
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
Check your WordPress timezone setting. Don’t use UTF +0, choose a city in your timezone from the list.