Some sites report “off by one day” errors when calculating end dates on new orders and memberships. What this looks like on the front end is setting someone’s end date to January 31, 2017 and then having it show up as January 30, 2017. Or expiration is set to happen at 12:00am, but it happens at 10:00pm instead.
This post covers some common reasons why this is happening and a collection of ways to set the various time stamp settings in your web stack.
What’s really going on?
In most cases, “off by one day” errors occur when your web server, database server, and/or WordPress install are disagreeing about which timezone to use for calculating dates.
Getting everyone to “agree” on the time zone varies depending on your setup, specifically if you are on shared hosting and have limited access to your server. In this case you may not be able to configure the time zone for one or more of the services listed below. That being said, making some or all of the suggested updates can help to resolve these time zone errors.
Settings In WordPress
To change the timezone in WordPress go to Settings –> General in the admin dashboard. You can also set the date format here, which is used by PMPro when displaying dates.
Settings In CentOS/Linux
Here is an article explaining how to change your timezone in CentOS. Use the correct timezone file (browse around the /usr/share/zoneinfo directory), but generally you should run these two commands when logged in as root. (Note: don’t copy the #)
# mv /etc/localtime /etc/localtime.bak
# ln -s /usr/share/zoneinfo/America/New_York /etc/localtime
Settings In Apache/PHP
Typically you need to add or edit a line in your php.ini document. Here is a list of timezones at php.net.
date.timezone = “America/New_York”
Settings In MySQL
Log into MySQL as root and run this query: (More information on time zones in MySQL.)
SET time_zone = ‘America/New_York’;
Making sure that all of these settings are in sync will usually fix any “off by one day” errors going forward. Some issues will be fixed immediately after changing these settings. Other issues will still happen since the timestamps in the database were set when time zones were out of sync. You’ll have to run queries in your database to update time/date fields after your time zones have been set correctly.
Some hosts or server setups will have different methods for changing the time zones as above. Searching the knowledge base of your host or opening a support ticket there may help. If you find a new solution related to above, feel free to comment and we’ll try to expand on the information here to cover as many scenarios as we can.
If you are still having issues related to dates and time stamps, please post to our member forums and we can help you fix things for your specific setup.