Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Generated occurrences' display times may be incorrect across daylight savings changes #22

Open
cogat opened this issue Nov 9, 2016 · 1 comment

Comments

@cogat
Copy link
Contributor

cogat commented Nov 9, 2016

(This applies to the previous version of Eventkit, but may still affect us)

From the client:

Sunday, 11/6, was a Daylight Savings time change for us, where we turned the clocks back an hour. We noticed that this had an unexpected effect on published, recurring event pages that you should be aware of for GlamKit.

We found that published event pages were showing the wrong time, an hour earlier than they should be, on the Exhibitions + Events calendar page, and in the EventKit admin listing. We have 3 ‘daily tour’ events that happen every day, between 9/5/16 and 12/31/16. We saw in the EventKit admin that the time for the repeats changed on 11/6 to be an hour earlier. We had to fix this by changing the original event to start on 11/6 and republishing so that it didn’t span pre and post daylight savings.

On the individual Event pages, we typically use the ‘Human readable date field override’, which ensured that the correct time was showing on the event page itself.

--

This sounds like a tricky one - we're generating occurrences in the local time zone, but is that the local time zone as of today, or as of the date of the occurrence?

To test: One would expect generated occurrences which span a daylight savings change to change UTC hour after the daylight savings change, but not displayed hour.

@jmurty
Copy link
Contributor

jmurty commented Nov 9, 2016

This problem shouldn't affect the refactored because, after finding a related issue, we adjusted the RRULE that generates future event times to be based on a naive datetime instead of a UTC one.

In effect, this should mean that a 9am event always occurs at 9am regardless of any daylight savings changes after the first event (and repeat rule) were created.

Of course, this is fine in theory but we need to actively confirm we handle this situation properly with targeted unit tests. Ask me for pointers to the related tests we have so far.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants