Recurring Events and Daylight Savings Time

[webdevstudios]

Hiya Tribe —

I’m Chris from WebDevStudios and I’m working on a client site that’s using The Events Calendar PRO. Since the DST clock change, we’re seeing a really weird issue with recurring events that I need your assistance with. First of all, this is on a multisite install. This is important because I was unable to reproduce the issue locally until I made my local instance a multisite.

The issue is that the times of the recurring events get pushed later or earlier depending on their relationship to the DST time change. So:

– Recurring events that start *before* DST begins and end *after* DST is in effect will have the correct time for the before DST dates but be an hour EARLIER after DST is in effect.
– Recurring events that start while DST is still in effect and end *after* DST ends will have the correct time for the during DST dates, but be an hour LATER after DST ends.
– Recurring events that start while DST is still in effect and span both changes (clocks back/clocks forward) will see both things happen — they will start out with the right time, have the time pushed an hour back while DST is no longer in effect, and correct themselves after DST begins again.

I haven’t tested, but I assume you’d get the inverse behavior for events that start when DST is not in effect and span both DST time changes.

The only workaround I can think of would be breaking the events up into pre-DST/post-DST/during-DST groups, but that’s a lot of work to dump on a client, so I’m hoping for a more permanent solution.

Thanks guys!

BTW, you can see an example of the 3rd scenario here, but I’ve tried all three locally: http://mhs.montclairschools.org/event/photography-club-every-wednesday/all/

[wellrounded]

The bug to notice on the link page above is that the event time changes by 1 hour after the next Daylight Savings change, on March 8, 2015.

Thanks!

[Brook]

What a thorough bug report! That is immense, thank you.

I am going to try and reproduce so that I can get it logged. I will let you know the result. Cheers!

– Brook

[webdevstudios]

Thanks Brook!

[webdevstudios]

Anything?
If there are hacks that I can apply to a plugin or the theme, I’d be open to that as well, but I didn’t see any actions or filters that could be tapped into to modify the behavior of the update_post_meta function when the recurring events are saved.

[Brook]

Howdy webdevstudios,

I am unable to reproduce this on a multisite or otherwise.

After some pondering I am wondering if this could be a server issue. Although you said you were able to reproduce locally as well. What is your timezone setup like, as defined in WP Admin > Settings > General? I set mine to Denver time as a test, and UTC. In both cases there was no shift. If your timezone setting is different from your server times, I could picture this happening, though certainly not in every case.

As a temporary fix, you could split the event series up and modify the times manually. Hardly ideal, but at least they will show the proper times for now.

One other thing that is worth mentioning, I have seen an incredible amount of plugins and even more than a few themes mess with WordPress’ PHP timezone environment setting, via things like date_default_timezone_set(). WP itself set that timezone to UTC, and a lot of plugins, ours included, rely on that universal standard. If a plugin changed it to one that is different this sort of issue could certainly happen. To test for this we would need to do a standard conflict test. But maybe you have already done the equivalent by testing in a local environment without other plugins?

Please let me know. Thanks!

– Brook

[wellrounded]

Hi Brook,

Thanks for your response. We have confirmed that there’s no timezone config problem on our servers. The production server itself is a standard hosted Centos Linux box with timezone set to Eastern, and the normal daylight savings config. In the recent daylight savings switch on Nov 2, we watched it jump an hour back correctly.

In the WordPress settings, the timezone is set to New York, and right now it says:
UTC time is 2014-11-11 7:30:06 Local time is 2014-11-11 2:30:06
This timezone is currently in standard time.
Daylight saving time begins on: March 8, 2015 1:00am.
These are all correct.

We have confirmed and replicated the issue on a dev server as well. The dev and production servers were set up by different hosting providers, so we’re fairly confident that it’s not a config issue or server issue.

That leaves a software conflict as a possible explanation, as you suggested. I will see if we can do a conflict test, and we will respond with further info.

Best,
–Jonathan

[Brook]

Thanks Jonathan! One other thing you might try, confirming that date_default_timezone_set works on your server. Some people evidently have issues with that not working, which I could see how that would cause this problem. Running a bit of code like this on your server should confirm whether or not your timezone can be changed to UTC. If the two echoed  times are not different that would be a bad sign.

Let me know how that goes. I did double check with the team and none of them have come across this either. So it’s not just my server that is behaving proper. Thanks!

– Brook

[webdevstudios]

Echoing that code did, indeed, print two different times.

I can test again locally with all other plugins disabled, but I’m pretty sure yours is the only one that cares about dates and times.

[webdevstudios]

Looks like it was a plugin conflict. I’ll start digging through the plugins to see which one.

Brook — would it be useful to you guys to report back which plugin I found that’s doing it (assuming it’s not one of our plugins)?

[Brook]

Absolutely. If you have a minute we would greatly appreciate it. And if I have any ideas on how to make the two plugins compatible I will pass them on. Although, odds are strong that whichever plugin is using that function I kept mentioning, date_default_timezone_set(). We are striving to make our plugin immune to that setting. In fairness other plugins should not be changing it, WordPress herself set it up as a global in wp-settings.php. But, that doesn’t stop it from getting changed sometimes so to the extent possible we are trying ignore that setting going forward.

Thank you! Let me know if you need anything else in the meantime.

– Brook

[webdevstudios]

Hey Brook, it was the Power Stats plugin that was the culprit: https://wordpress.org/plugins/wp-power-stats/

If that plugin is active either network-wide or on a single site, it will cause this DST time shift. Interestingly, I found that when I went back into events that were created while Power Stats was active, the times were *still* off, but only after Daylight Savings begins again in March (at which point the times were set *back*) as opposed to them being off for both changes.

I believe the reason I was unable to reproduce on a single site initially was because we use Migrate DB Pro and the plugin was active network-wide but my local hadn’t been set up for multisite, so Power Stats wasn’t active in my initial tests.

[Brook]

Howdy webdevstudios,

Thank you. So I just downloaded that plugin, version 1.4, and saw the same problem. When I commented out line 30 of wp-power-stats.php and line 30 of trunk/wp-power-stats.php, it worked properly in the Events Calendar. Both of those lines contained the following code:

date_default_timezone_set(get_option(‘timezone_string’));

You might reach out to the plugin dev and see if removing those lines cause a problem for Power Stats. They almost certainly do. I will bring this up to the powers that be as well. When possible we like to reach out to plugins that are known to conflict and see what we can do to work together. If you want to reach out to them as well that can not hurt. Thanks for helping us get to the bottom of this.

– Brook

[Brook]

Quick note, I had to comment out that line and update the relevant event from the backend after saving the commented out file. Just saving it did not fix things.

– Brook

[Brook]

I just wanted to update you and let you know that we reached out to the developer last week to see if there was anything we could to work together and make the plugins buddies. We have yet to hear back, but hopefully we will soon. Thanks again for reporting this. I am going to close out this topic since it has run the course at this point. Cheers!

– Brook

[Author]

Posts