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.
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.