Incorrect Start Date

[Beth Moeller]

I have gotten back to my time zone issues, but found a couple of interesting things.

First, if an event spans more than one day, it appears that the start date is actually the end date. It can be seen on http://arts-spark.com/calendar/. If you look at June 11, the Rip and the Taylors event is actually June 10 — and that is what I”m seeing on the backend. This is true whether my timezone script is running or not. I took my script out to test this one. The event is in my database as 8:30pm June 10 to 12:30am June 11.

The other piece is that when I call eo_event_start within a script, it throws 500 errors. I was testing the start date issue and when I call just eo_event_end, the script is fine, but reporting 1 day later on that event.

This was an imported event from a different timezone using the sync function. The event is actually June 10 from 7:30pm to 11:30pm CST, but was converted to Eastern time on import, resulting in it spanning two days. When I add an event manually, going past midnight, it’s fine. My feed is coming from http://peteweise.com/feed/eo-events.

[Stephen Harris]

Hi Beth,

I’ll need to investigate this a bit more, but this might be a known issue with the iCal feed. Here’s the original event’s iCal entry:

DTSTART;TZID=America/Chicago:20160610T193000
DTEND;TZID=America/Chicago:20160610T233000
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=SA;UNTIL=20160625T003000Z

and here it is on your site:

DTSTART;TZID=America/New_York:20160611T193000
DTEND;TZID=America/New_York:20160612T003000
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=SU;UNTIL=20160619T003000Z

Oddly, the time remains the same: 7:30pm (193000) despite the timezone changing. What caught my eye, though, was that the BYDAY attribute for both of them are incorrect.

The issue seems to be in the source feed – that is, your Blog is correctly creating the event to repeat on the Saturday (‘SA’). The same bug is then causing the second’s site feed to display Sunday (‘SU’).

I’ll look into this and get back to you as soon as possible.

[Stephen Harris]

I’ve managed to track this down.

In the recent 3.0.0 update, if a city timezone was specified (i.e. not just a UTC offset) then the iCal feed would render the date in the specified timezone, and not convert it to UTC as it use to.

Since the plug-in had been converting times to UTC for the feed (UTC is the safest timezone to work in, as almost all calendar applications understand it. For other timezones there is no consistant way of labelling a timezone), it would also (potentially) have convert the day the event repeats on. After all, the Rip and the Taylors event actually repeats on Saturday in UTC.

In short, that bit of code that converted the day did not take account of whether the event’s dates were being rendered in America/Chicago or UTC – hence it converted the Friday to Saturday, shifting your event by a day.

The same bug mean that your second site’s feed shifted the event from a Saturday to Sunday.

I’ll fix this as soon as possible, but an immediate fix in your case is to comment out these lines: https://github.com/stephenharris/Event-Organiser/blob/68e1641197a2555b2415cf9d82de5ee58ae20770/includes/event.php#L963-L984

[Beth Moeller]

Hi Stephen,

Thank you for the quick turnaround. I commented out the lines in the event.php page, deleted all the events from that feed (deleted permanently, not just moved to trash) and checked pages to make sure they were truly gone from the database. Then I commented out my filter and re-imported the feed. I’m still seeing the problem.

http://arts-spark.com/calendar/

Beth

[Stephen Harris]

Have you fixed the bug on http://peteweise.com?

[Author]

Posts