I am seeing an issue where repeating events do not appear on the last day they occur, while ongoing all-day events appear on the last day they occur but show the time as “Midnight” instead of “All Day.” Two examples:
This exhibit repeats M-F through Dec. 17 (today) which is the last day of the exhibit. It does not appear on today’s calendar, and the only way I can get it to appear is to change the end date to Dec. 18 - which then makes the event say "Repeats M-F (to Dec 18) which is not correct and may confuse people.
This exhibit runs all day through Feb. 9. While it does appear on the Feb. 9 day calendar, it shows a time of “Midnight” instead of “All Day.”
Not sure if this issue is specific to our instance or if it is a bug others are seeing as well.
I think Jon’s right, we’ve implemented a few repeating events fixes in recent versions and I recall fixing this one.
One way to confirm that upgrading LiveWhale would fix this for you is to reproduce the series on your dev site and see if it still occurs there. (Or, you can run a full content sync of events from prod to dev.)
Thanks, Karl. I guess I didn’t realize software updates were not pushed to our site automatically and that we had to implement them manually. I’m not sure our web dev team knows that either - and they would be the ones to do those upgrades, not me. I’ll check in with them about this.
Jen
I wanted to follow up on this topic because I finally had a chance to review it on our Dev site in preparation for upgrading, hopefully next week. As of LiveWhale 2.18.0, it looks like both of the specific issues @jroupe noted have been fixed.
Repeating events now show their last instance. According to the 2.18.0 release notes, this was caused by repeating events that crossed a DST boundary.
All-day repeating events now show the time on the last instance as “All Day” instead of “Midnight”. This was in the release notes for 2.17.0, “Fixed an issue where multi-day all-day events could sometimes erroneously show “12:00 am” instead of “All Day” on their final day in calendar list and week views.”
However, it seems there is still an issue with a related situation - multi-day events that have start and end times. Take this for example…
The event starts at 5 p.m. on 1/21 and ends at 8 a.m. on 1/23. The first event on the Week view calendar looks great, showing the start and end times. The second instance shows “all day”, and the last instance says “12 a.m.” I’d argue they should all have the same format as the first instance.
Then, the Day view that includes the final event looks like this…
Now the time says “all day” which is not true since it ends at 8 a.m.
I have reported this issue to our personal support email. I just wanted to add to the conversation here in case anyone else was having a similar issue and wondering what has/hasn’t been addressed in the latest version.
Thanks, Jon and Karl. I met with our web dev team and we are going to upgrade to the latest software version next week after they complete testing. I’ll let you know if I see any further issues, including the one Jon is still seeing with multi-day events.
Jon and Karl,
We have upgraded to LiveWhale 2.18 and that fixed the issues I was seeing with repeating and ongoing events. However, I am seeing a similar issue as Jon for multi-day events with start and end times. We have an event called Hacking for Humanity which runs from Noon on 1/24 to 5 p.m. on 2/7. There are issues with how the event appears in an upcoming events list for the first and last events. See the event listing here: CMU Events Calendar. The first day says shows a time of “Noon-5 p.m., Jan. 24-Feb. 7” which is not correct - it should read in the same format as Jon’s above, “Noon Jan 24 - 5 p.m. Feb. 7” - so while his is correct mine is not. But just like Jon, the last day of the event, 2/7, shows a time of Midnight when it should say “Midnight-5 p.m.” So perhaps the first day issue is specific to CMU, but it seems the last day issue might be a wider bug affecting multiple schools?
@jroupe I just realized that I have some JS that reformats the time for multi-day events. So the format you are seeing for the first day is what LW outputs, but my JS changes it. That’s why ours are slightly different.
But you are right that the default output is wrong, and misleading. (which I suppose is why I wrote the JS in the first place).
And like you said, the issue remains with the last day. I’d argue that all days of multi-day events should show the time the same as the first day (with the range).
Thanks y’all – the short version is, we agree this is a buggy situation and are in discussions on how to fix it most effectively in core for all the various permutations of repeating and multi-day events (with and without start/end times). We’ve got one open issue for it which we’re hoping to land in our next version, hopefully that will address the last-day situation in a way that improves this for everybody.
