Timezone data not being utilised

The tzignore and tzoffset parameters have been removed, as they never worked quite right and directly conflict with some more recent changes I made to the way the plugin handles time zones.

At the moment, the plugin only shows events in the time zone of the feed itself and cannot be adjusted. I have another request for support for this so I’m investigating adding in a new option to make adjustments between the feed’s declared time zone and the WP time zone setting.

This gets very complicated very quickly, owing partly to the fact that the ICS Parser library already does its own time zone adjustments for the feed, but WordPress’s time functions do not play nicely with that, and end up causing doubled-up time zone adjustments.

In the end I bypassed all of that, and wrote my own time display functions that do not make any time zone adjustments, so I can get ICS Parser’s times to display in the local format.

It might seem like a straightforward thing to shift the times by an arbitrary number of hours, but unfortunately there are two issues: 1) events that start or end on a different day as a result of the shift, and 2) additional calculation adjustments that need to be made if the two time zones in question start or end Daylight Saving Time on different days.

The main reason any of that is a problem is that the events get sorted into hierarchical arrays, by year, month, day, and then time. In most cases, a time zone shift would just be a matter of changing the text string containing the time, but if it shifts an event onto a different date, the entire subarray of data for that event needs to be moved to a different place in the array.

Anyway… that gives you a glimpse into the challenges this poses, and why for most of this year I’ve just left the plugin with the limitation of using the time zone data provided in the feed itself. I do think it’s possible to solve this issue though, so I’m going to take another look at it.

Cheers, thanks for the update and the explanation of the difficulties. I can see the issues and look forward to this improvement when you manage it.

For the time being I’ll write myself a small conversion script for my individual calendars and then import these into wordpress, much easier to do for an individual calendar where I know the timezones and dates of daylight saving. ??

I might also try using radical and/or DAVx5 to import and export the calendars in a my local timezone. I’ll let you know if that works in case there is code you can borrow.

Good luck and thanks heaps for the plugin. ??

So after spending a few hours looking at my .ics files and CalDAV clients wondering what the simplest method would be I’ve I noticed that my .ics files already contain timezone data for each event and realised that the simplest solution is NOT to convert the times in the event data but to convert the display of those events into the desired timezone.

Reading your description of the issues in more detail leads me to propose that we need to convert all times into the specified site simezone **before** the events get sorted into hierarchical arrays.

The DateTime class seems to do what is required but I haven’t tested it yet.

I see your source code is in https://plugins.trac.www.ads-software.com/browser/ics-calendar?order=name which I’ve never used before. Is it fine for me to copy this code into a git repository to play around with?

Edit: HOW do I download a copy of the source code to play around with??

• This reply was modified 4 years, 5 months ago by storyjesse.
• This reply was modified 4 years, 5 months ago by storyjesse.

@storyjesse Plugins here are required to be GPLed so you can do whatever you like. (Just download the plugin directly here.)

Be aware though that I’ve already spent weeks working on this issue. You have to understand how DateTime functions manipulate times based on the server OS time zone setting, and WordPress date/time functions use the WP time zone setting (in ways that conflict with each other, so WP plugins are only supposed to use the WP functions). On top of that, the ICS Parser library (which I use for the initial conversion of the raw ICS data into a PHP array — no small task) does its own time zone adjustments first.

The plugin DOES already use the time zone data in the feed; it just doesn’t allow you to shift the times from that time zone into another one.

After those aforementioned weeks of fighting with the PHP and WP time functions — which were always doing unwanted additional modifications of the parsed times — I ended up writing my own time display function for the plugin. The problem with the PHP and WP functions is that they ALWAYS want to take time zone into consideration as they’re working with a full datetime value. ICS Parser has already split the date and time out into strings, and I just needed to have a way to change the time display format, e.g. 4:30pm, 16:30, 16h30 etc.

In order to do what you’re suggesting, any change would have to be made to settings going into ICS Parser before it runs. But my extensive testing of that found no good way to get it to do a shift between the feed’s time zone and a site’s local time zone. But it’s always possible I missed something.

@storyjesse One more thing I neglected to mention (I shouldn’t respond to support threads right when I get up in the morning!)… I believe the proper way to do time zone adjustments should be to give ICS Parser a time zone to work with. It has a property for that: defaultTimeZone. I am already telling it to use the “local” time zone from the WP settings. (This is line 344 in class-r34ics.php.)

The problem is (and I may be mistaken as it’s been several months since I last tried to do anything with this), I think ICS Parser only uses this base time zone if there isn’t specific time zone data in the feed itself. If there is, it uses that instead. So it doesn’t provide a way to tell it to shift the output from the feed’s time zone to an arbitrary local time zone.

I’m going to have another look at this today and see if I can figure out something that eluded me the last time I worked on it.

(One other related element of this: there’s a vestigial tz property in this class, which is being set to UTC at line 71, but at the moment that property is not being used anywhere. It used to be referenced in line 344 but I removed it when I realized using the WP time zone in that spot was yielding the most consistent results.)

I’ve been poking around the source code of the ICS Parser library and I found a method I hadn’t been previously using (because the sparse documentation didn’t make it clear to me how it should be used), which should handle these time zone conversions. Working on an update now.

OK, I’ve got it all sorted out and I finally have what appears to be a clean way to both automatically adjust feed times to the local WP time and to override that with the new tz parameter I’ve just added.

Version 6.0.0 of the plugin is on its way to the repository now.

Previously, the plugin was just displaying events based on the timezone of the ICS feed itself, ignoring local times. Now it is automatically converting those to the local time set in Settings > General > Timezone. In most cases, those have been the same, so it shouldn’t make any difference.

The new tz parameter allows you to change the feed to any arbitrary timezone, if you don’t want to display it in your site’s local timezone.

This update also includes a major update of the ICS Parser library that removes an annoying set of dependencies that represented 82% of the overall code size of this plugin!

(By the way… it turns out that the method I found in the ICS Parser library was not the solution I needed… but it tipped me off to a better way of using the parser’s calculated Unix timestamps in conjunction with wp_date() to calculate the start and end datetimes of the events.)

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

Yay!! Thank you so much!
Its almost 1am where I am so I’ll upgrade to version 6 in the morning and test it. Sounds like you got usability perfect to me though. Fingers crossed there are no bugs. ????

Yes, let me know how it goes when you have a chance to test.

As it turns out, I did find a rather significant, but small, bug with the changes I made. I reverted the stable version temporarily, but I’ve now fixed that bug, so version 6.0.0.1 is on its way out.