EC Pro not handling GMT to BST transition correctly

[Alan]

I’ve just upgraded to EC Pro specifically to use recurring events. I set a recurring event running from (say) 1000 to 1200, every day, from 15th March to 15th April. All is fine until 28th March when British time flips over into BST and gains an hour. My event on 29th March apparently runs from 0900 to 1100 which is NOT a good thing.

I have WordPress set to “London” time (I tried changing this manually as an experiment to UTC+1 as suggested in thread https://theeventscalendar.com/support/forums/topic/wrong-date-time-set-to-utc-0/ but it made no difference – in any case having to change timezones manually is so 1980s.)

I have set EC Pro to “Use the local timezones for each event” and (ticked) Show timezone.

(by the way I am retrospectively adding a 2015 calendar, this is not a mistake. The principle carries over to this and future years).

Before the time flip, it shows “28 March 2015 @ 10:00 – 12:00 GMT |Recurring Event (See all)”
Afer the hour changes, it shows “29 March 2015 @ 09:00 – 11:00 GMT |Recurring Event (See all)”

… for the SAME DAILY EVENT.

What it needs to show is “29 March 2015 @ 10:00 – 12:00 BST |Recurring Event (See all)” or “29 March 2015 @ 10:00 – 12:00 GMT+1 |Recurring Event (See all)”

in other words, the TIMES which have been set must be sacrosanct, and must be displayed.

If I need to change any settings to get this working please let me know where to look. My wordpress installation is aware that my “local time” is correct. It says on its general settings page:

Universal time (GMT) is 2016-10-03 13:34:27. Local time is 2016-10-03 14:34:27.
This timezone is currently in daylight saving time.
Standard time begins on: 30th October 2016 2:00 am.

So if WordPress knows when the time flip occurs, EC Pro can presumably find that out and make the necessary adjustments to the displayed time. This is a major issue for me since I have committed to launching the new calendar in the next 2 weeks …. just before the hour is going to change once more!!

I’m running on a development server right now so not possible to access the site yet.

[Cliff]

Hi Alan.

Thanks for your detailed question.

Unfortunately, this is a known bug at this time.

FYI: If you use a “manual UTC offset” timezone, your events won’t ever take DST into account. However, the bug exists when you have your WordPress or event timezone set to a location-specific timezone; it should know how to handle DST for that location-specific timezone but doesn’t at this time.

I’ll mark this ticket as Pending Fix, which means this thread should receive a reply once the applicable fix has been released. I cannot guarantee when it will be fixed as it’s in the development team’s hands now. They need to assign it, code it, test it, and schedule it for release.

I apologize for this issue and appreciate your understanding and patience.

[Alan]

OK, noted and look forward to the fix.

I can add to this now in as much as I have found a workaround. You have to go to the first instance of a recurring event after the time flip has occurred (e.g. 30th October 2016) then from the admin bar go to “Edit Events/Edit Future Events”. This splits the event into two and all you need to do is check and re-enter the correct times as appropriate and hit Update.

It’s not ideal since it needs manual intervention twice a year but it does work. Might help someone out there who has the same problem. I found that making the timezone visible is helpful.

A

[Cliff]

Thanks so much for sharing your workaround, Alan.

I have shared it with our team internally as well as being here on the forums for others to possibly find.

[Geoff]

Hi Alan.

We wanted to let you know that we were unable to get a fix for this issue in the latest maintenance release that we shipped this week. Our team did spend a considerable amount of time looking into the issue of Daylight Savings Time not being taken into consideration with an iCal file export but were unable to replicate the issue after many repeated and individual tests.

We are still interested in pinpointing why the behavior exists in this case but it will take some more digging to properly diagnose whether the issue exists in all cases before we can plan a release for a solution.

In the meantime, we would really appreciate it if you would update your plugins to the latest versions and test whether the issue persists. If it does, then it would be great if you could run through the steps outlined in this guide and let us know if you notice and difference in behavior when your site (or a separate test site, ideally) is in a default WordPress environment.

Thanks so much for bearing with us while we work on this together.

Geoff

[Support Droid]

Hey there! This thread has been pretty quiet for the last three weeks, so we’re going to go ahead and close it to avoid confusion with other topics. If you’re still looking for help with this, please do open a new thread, reference this one and we’d be more than happy to continue the conversation over there.

Thanks so much!
The Events Calendar Support Team

[Author]

Posts