Important Upcoming Changes to Dates and Times in Event Espresso

This post is important news for any Event Espresso 4 user who has their WordPress website using a UTC offset for its timezone setting instead of a timezone string (e.g. city/region). If you have your website set to use a timezone string (e.g. a city/region) then you will not be affected by anything in this post. Check Your Date and Time Settings! – Log in to your WordPress website and navigate to: Settings > General > Timezone

An update is coming that will fix some bugs we discovered related to users who set their WordPress Timezone to a Manual Offset from UTC. We wanted to give some heads up on this update because it could impact the dates and times on your Event Espresso powered website. Here’s a rough outline of this post for those of you who want to skim to the parts that impact you:

1. Backstory – Outlines some basics around the Manual Offset from UTC setting for your website timezone and why it generally is a bad idea to have your site set to an offset as opposed to a city/region.
2. Problems – The issues we discovered and fixed.
3. What this means for you – How the fixes will affect some websites.
4. Recommendations – What we recommend to prepare for this change and deal with any potential impact you may experience on your website.

Backstory

Every WordPress website has the option to set what you want to use as the timezone setting. In WordPress UTC offsets are an option for backward compatibility but are really a horrible option for user’s to use for a few reasons:

1. Some UTC offset option are completely invalid. Meaning, there is actually no region in the world that uses that offset.
2. UTC offsets do not automatically account for Daylight Savings Time (DST). This means if you use a UTC offset to represent the time where you live, and where you live observes Daylight Savings Time, then you’ll need to adjust your offset whenever Daylight Savings Time is in affect. Whereas, if you pick a city/region (such as “America/Vancouver”) this is all taken care of for you automatically.
3. If the region of the world you live in changes its timezone offset (it does happen, read about what happened in Cancun in 2015), then the offset you chose is now invalid and you’d have to remember manually to make the change. Whereas using a city/region for your timezone offset will again automatically adjust for any change when your host updates the server.

We have been warning users about using UTC offsets for a while, even going so far as to adding a warning if they create their first event using a UTC offset for their timezone. Despite this, many of our users continue to use UTC offsets and so we have tried to support this.

As a part of supporting UTC offsets, we’ve done the following things in Event Espresso:

1. We converted all UTC offsets to the closest matching timezone string (city/region) for that offset within the internal timezone map supported by PHP.
2. For invalid UTC offsets (where there was not match in the php timezone string db on the server), we converted it to the closest valid UTC offset and use the timezone string for that location.

This means, that for the most part, Event Espresso would work with timezone strings instead of UTC offsets and consistently apply that to all saved dates and times within our system and thus to correctly account for things like DST etc. for the majority of our users who have their website set to a UTC offset.

The problems

The problems we recently uncovered are:

• Timezone maps can vary server to server and between php versions whereas an assumption was made that they remained pretty consistent.
• There could be more than one match for a given offset because the timezone maps contain historical records and the first match could be for a timezone that is no longer exists today. For our conversions we were only using the timezone string for the first match and not checking if that match actually existed today. We corrected this.

What this means for you

Most users do not experience trouble with how things were currently setup because for the most part, website owners set their timezone setting once and don’t change them. So even though Event Espresso would be converting UTC offsets incorrectly internally, the user wouldn’t notice anything because Event Espresso would converting it consistently. Where this becomes a problem however is:

• When the website timezone is changed. Now the conversions from the saved offset might result in unexpected values because the original offset used to convert was actually incorrect.
• In the future, when per event timezone settings are made available. Because then, the timezone conversions will be incorrect.

Once we became aware of the problem, we recognized it needed fixed because we don’t want anyone to run into this problem when they do change their timezone settings or when we release new features.

In the next update of EE4 (4.9.47.p) , we’re going to release an update that will correct the issues we uncovered. However, some affected users may not realize the times on their site are in the wrong time zone and when our code begins converting their UTC offset to a more correct timezone, it will appear to them (and to their website visitors) that those times have changed. For example, instead of having an event start at 9am Pacific Time, it may appear to begin at 8am Mountain Time. There’s no way for us to accurately predict what specific UTC offsets will be affected because of the variations in server environments so that means that some manual intervention will be needed to correct any discrepencies.

To that end, we will be releasing in the next release of Event Espresso a “Datetime Offset Fix” tool that will make it easy for you to add or subtract an offset to all your existing dates and times in the Event Espresso system at once. This tool will be found on the Maintenance page section of your website and is a simple form for adding the offset you want to be applied to all dates and times found in Event Espresso. Once you provide the offset and click submit it will automatically go through your database and apply the given offset to all your Event Espresso datetime fields.

Our support team will also be on hand to assist any of you with any issues you may encounter when this change is rolled out.

Recommendations

We strongly recommend that if you are using a UTC offset as the timezone setting for your website you change your site to use a city or region instead. We recommend doing that in the next release of Event Espresso which will include the Datetime Offset Fix tool so if needed after the change, you can use the utility tool to correct any issues you see with the time displayed. How would it work?

1. Let’s say before you make any changes, the start time on one of your events is 6pm.
2. You go to Settings -> General in your WordPress admin and from there look for the Timezone option. Then select from the dropdown the closest city/region to what timezone you want your website to be in. Once that’s selected click the Save Changes button.
3. Now check the start time on the event your observed earlier. Is it still 6pm? If so, then great! No further changed needed. But let’s say after the change you observe it’s now showing 8pm. In that case you want to go to Event Espresso -> Maintenance and then click on the Datetime Utilities tab.
4. Since the current time you observed for your start date of your Event is 8pm and you want it to be 6pm, that means all your times need to have an offset of -2 applied to get them back to displaying the correct time. So in that case you need to make sure the Offset field on this page displays -2. You can either click the down arrow in the field or enter -2 manually. Then click the Apply Offset button.
5. Once you click the button the page will refresh and show you a progress bar along with what tables it is going through to adjust the offset. The length of time this takes will depend on how many records you have in your database. Once its done you will be returned to the Datetime Offset Tool page. When that happens, go back to observe the start date for the event you are monitoring and you should now see the correct time.