The problem is that one day events imported via an .ics file display as two day events, i.e starting on one day and ending on the next day. This means that many calendars cannot be imported without manual repair on a per event basis, thus defeating the utility of both individual file upload or scheduled imports.
There are many articles and public support tickets on The Events Calendar’s knowledge base and public support tickets that describe or refer to this issue. However, none that I have found provide a solution. It would be fantastic for Modern Tribe to look into a get a handle on this problem or at least provide some documentation on the expected behavior.
Modern Tribe’s support folks will often ask for two things to be be done before they start troubleshooting and issue – turn off all other plugins and revert to a default WordPress theme like Twenty Seventeen. This is often difficult or impossible given the plugin’s licensing model and other site configuration concerns. Thus, a pretty high bar is set for those seeking a solution, which could contribute to why this issue has persisted.
Below is a way that you can reproduce this problem using the default WordPress theme with no other plugins installed.
Steps to reproduce
- In the Admin area, create an event, making sure to check the “All Day Event” checkbox.
- Save the event.
- Browse to the public URL of the event, and click the “ICal Export” button and save the .ics file to your computer.
- Return to the event and in the Admin area and delete it. We are going to recreate it using The Events Calendar’s .ics export.
- Go to Events > Import and select “.ICS File”.
- Upload the file that you’ve just saved. Remember, we are just importing one event, the all day event you created earlier.
- When you click “Preview”, you’ll note that this imported event is listed as “All Day” in the preview table row.
- Proceed with the import.
Once the import in complete, view the public URL. You will see that that the event that you created as a one day event now is listed as a two day event – the day you designated when you first created the event via The Events Calendar UI and the next day.
Example: January 25 – January 26
Obviously, this is incorrect. Your one day event is now a two day event. Those showing up on that second day are pretty likely to be disappointed.
Now, edit the event. You will see the time zone set as UTC. This must be the default behavior, since there was no timezone designated in The Events Calendar’s own export. In fact, even if you edit the ical file manually and define a timezone, it will make no difference.
If you change the timezone to either your local UTC offset (Ex: UTC-5) or your local timezone (America/New_York), the event with properly show the single day event.
Further, when the manually created event is created, The Events Calendar will ALWAYS add a extra day, regardless of the time zone selected.
This behavior is different from events with defined times. Those events honor the time zone in WordPress in Settings > General > Timezone.
The Events Calendar is then set to honor the above by going to Settings > Time Zone Settings > Use the side-wide time zone everywhere.
As always I encourage comments and corrections. Let’s see if we can get a handle on getting this feature to work predictably.
I’ve provided essentially this identical description of the issue to Modern Tribe, but I thought that making it public would help some folks struggling with the same issue.
My ticket was responded to. It turns out the that The Events Calendar correctly stores the event in the database.
2019-02-05 00:00:00 // start
2019-02-05 23:59:59 // end
The problem is in the display logic that determines how those values are interpreted on the UI layer. The support person is going to verify with the engineers that this is a bug.
The support response was that setting Time Zone Mode to Use manual times zone for each event would correctly display an imported all day event. This is true. The downside of doing so, as I pointed out to the support person, was that making this settings change would alter the display of all previously imported events. This is, of course, impractical. There are far more specifically timed events than all day events. I am not looking to create more issues on our production calendar in this way.
At this point I had reached an impasse with this individual and asked the ticket to be escalated. While I appreciate the efforts of front line support, we were in a forest for the trees situation. Front line support is typically looking to quickly dispense with issues without consideration of broader customer needs. I get that, but I also need to import and display events, as well as understand the feature’s behavior.
I was then connected to an engineer who recognized the issue and said, in the case of .ics files mixing all day and specifically timed events, that the time zone should be included. Great, this was as I suspected, but as I’ve mentioned above, I was not looking to enter a trial and error phase. I was also unclear on how the time zone was to be included, whether at the VEVENT level or at the start of the file. In this case adding our EST time zone to the file using the example given by the tech solved the issue. We have more testing to do, but my basic example was proof of concept and a way forward.
I spent a lot of time that I didn’t have on this issue. I wish that The Events Calendar had more detailed and specific documentation on how this feature works. I am writing this in hope that I can save folks time, with the recognition that product updates could easily obviate this article.