Daylight savings times resulting in wrong calendar times

Somehow in trying in trying to fix this the current times are now all an hour early! Don’t know if this is a cache thing after adding the fix and then removing it. The times are still wrong at some point though!

Hmm… I’m sorry to hear this is happening. I’m not sure the problem resides with the plugin though, as it’s not directly making any time zone calculations. There’s an open source code library included in the plugin, ICS Parser, that is doing the work of calculating times.

I know ICS Parser has a few issues with the many inconsistencies in how different servers format ICS data, especially around the inclusion or omission of time zone information.

I think it’s possible this is where we’re hitting a snag with your feed, assuming you are in the GMT time zone.

I took a look at your raw feed, and I see there is no time zone information at all in the feed. It’s possible that the ICS Parser library is assuming U.S. DST start/end dates when a time zone isn’t specified.

Have you tried using the tzoffset parameter? (I may not have that feature documented on the admin page.) Remove the tzignore parameter and add this instead: tzoffset="Europe/London". I’m not sure this will work, but it’s the first thing to try.

• This reply was modified 5 years, 2 months ago by room34.

Thanks, I’ll try the tzoffset code and see what that does. I guess beyond that I might need to contact the guys who supply the feed (it’s from a Church Admin service) and see if they explicitly specify a timezone in the feed?

Hmm… I’m observing something very odd when I test this myself, but I think it may work OK for you.

Since your feed doesn’t include time zone data, if I put it into my test site with no tzoffset, your events show “my” time… Sunday services starting at 3:45 am, and then switching to 4:45 am on October 27.

If I do put in tzoffset="Europe/London" then I get your correct times (9:45 am) up until October 27, when it reverts to 4:45 am.

If I set both tzoffset="Europe/London" and tzignore="true", then I get 8:45 am until October 27, and 9:45 am after.

Strange… clearly there are still some quirks in the ICS Parser library (which I didn’t write) that I still need to unpack.

I think what’s happening is that if the difference between “local” time and UTC is non-zero, it’s doing calculations, but if it’s 0, then it’s not. So during DST, your offset is +1 and it’s calculating times for DST, but on October 27 your offset goes back to 0 and it stops doing any adjustments, and just relies directly on the time relative to your web server.

I think this may end up not being an issue for you, however, since your server is in GMT/UTC. Try just using tzoffset="Europe/London" and removing tzignore="true" as I suggested above, and let me know if it resolves the issue for you. Thanks!

Edit: Yes, if this does not resolve the issue, I would recommend contacting the Church Admin service and seeing if they do, or can, include the time zone data in the ICS feed.

• This reply was modified 5 years, 2 months ago by room34.

Thanks, I’ve tried the offset addition and it doesn’t seem to be working. There could be a cache issue as some of my earlier changes took a little while to update but I think it should have updated by now.

I’ll contact the church admin guys to see if they can add the timezone in the feed.

As far as caching goes, you may want to use the reload="true" parameter. (I see that’s not in the documentation either!) By default the plugin uses WordPress transients to cache parsed calendar data for 10 minutes; setting reload="true" will force the full feed load/parsing to happen on every page load. (Don’t leave this on once you’ve got things sorted out.)

Thanks, tried that but no joy. I’m waiting to hear back from the admin guys to see if they can add the timezone to the feed.

OK, thanks. I think this does point to an issue that may be with the ICS Parser library itself, or may be the result of some of my workarounds. (I’ve been doing this long enough to know that 90% of the time the problem is my own, no matter how convinced I am otherwise.)

There definitely are some issues with how ICS Parser handles time zone calculations in feeds that don’t have time zone data, but I think I made a critical mistake in my workarounds, overlooking your exact scenario: having no time zone data in the feed and also actually being in GMT/UTC time.

I am going to do a bit of additional debugging on my end using your feed.

Thanks, I appreciate that.

OK, here’s the situation: There’s a block of code I wrote to work around some time zone calculation issues in the ICS Parser library, and I even added comments in the code indicating that these workarounds may need to be removed in the future if ICS Parser fixed the problems.

I have since rolled a new version of the ICS Parser into my plugin, and I think the time to remove the workarounds may be now. I just tested removing those workarounds, and I found that your feed was showing the correct times, both before and after the DST switch.

To avoid disrupting existing users if the workarounds are still needed, I added a new parameter to allow us to test bypassing the workarounds, cleverly named…

bypassworkaround="true"

This appears in version 4.1.2, which I have just checked into the repository. Please update to that version as soon as it’s available to you, then add bypassworkaround="true" to your shortcode and remove the other time zone-related parameters (tzoffset and tzignore).

If you find it’s still showing times before October 27 one hour early, try adding tzoffset="Europe/London" back in.

Let me know how it works!

• This reply was modified 5 years, 2 months ago by room34.
• This reply was modified 5 years, 2 months ago by room34.
• This reply was modified 5 years, 2 months ago by room34.

Thanks! I’ll keep an eye on the plugins page for the update and let you know how I get on.

Really appreciate your quick response on this.

I think we’re there. I’ve had to add…

bypassworkaround=”true”
and
tzoffset=”Europe/London”

But that’s now working before and after October 27th.

Massive thanks again!

Thanks! I have a feeling that there are still some issues with the ICS Parser library. Eventually I will phase out the workaround code so the bypassworkaround parameter will no longer be needed, but it won’t break anything, so you should be set. Let me know if I can help with anything else.

Excellent, thanks again for the speedy resolution.