-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with date rollover for timezone adjustment in ics2rem #8
Comments
Good point, I guess we have to adopt https://github.com/jspricke/python-remind/blob/master/remind.py#L372 the same way as https://github.com/jspricke/python-remind/blob/master/remind.py#L398. Looking through it, do we need it for all other date strings (tend, rrule) as well? Maybe extract it into an extra function? Would you be willing to test such a patch (or do you want to implement it)? |
I've implemented a quick fix for the dtstart and dtend properties, but looking at rrule, this might be a bit trickier. A solution would need to take care of transforming weekday recurrence as well. |
In fact, timezone transformation for recurring events seems like a difficult problem in general. For example, how do we deal with the following case? Location A has a recurring event every Monday at 15:00. Location B is one hour ahead of Location A, but in addition follows a different schedule for daylight savings time than Location A. We would then need (at least) two different remind entries which apply at different times of the year corresponding to different time offsets. This seems like a problem which should really be handled by remind itself. Maybe there's some user function we could include at the beginning of every generated remind file that does this, but I'm not sure if remind's timezone handling is good enough for this. |
Thanks a lot for the partial fix! I will leave this open for now. |
When using the ics2rem program, if an event falls on a different date in local time than it does in the original timezone, this different date will not be reflected.
For example, if an event occurs on 26 February at 14:58 UTC, then in a timezone at UTC+11, this would fall on 27 February at 01:58 local time. However, ics2rem will report that the event falls on 26 February at 01:58 local time.
The text was updated successfully, but these errors were encountered: