Closed c-leitner closed 12 months ago
Based on your description, it seems like the dates are being parsed based on machine time, somehow, instead of the timezone specified in the calendar.
A few things to look at:
1) Look at your ICS feed to see if it specifies timezone at all in it
2) I've looked at https://github.com/icalendar/icalendar#parsing-icalendars briefly (which is what we're using to parse the feed), and it looks like we could expose the timezone of the time using something like event.dtstart.ical_params['tzid']
so that might be useful for debugging.
3) As you know, I'm open to PRs -- if we need to pre-specify timezone before parsing an extra casting step to rectify, I'm cool with taking a look.
I've delved deeper into this topic. The "VTIMEZONE" ical tag can appear multiple times at the beginning of an ical file. Each event then uses either UTC time or a timezone specified in a "VTIMEZONE" section. I've tested it on two systems now. The timezone used for generating the output is always the system timezone. I believe it would be beneficial to include an option to specify the output timezone in the first line of the config. I will create a PR as soon as I figure out how to implement that functionality
I examined the library https://github.com/icalendar/icalendar#parsing-icalendars. The solution is simply to set the server time correctly, which poses a challenge when building with tools like GitHub Actions. The parser does not offer a way to modify the output timezone.
Bummer. Thanks for your investigation.
@c-leitner
Sorry for the late reply but this might help others as well.
I was having the same issue but I set the following in config.yml
and that resolved it, you may need to set to a different timezone if you aren't in eastern time though
timezone: America/New_York
I have encountered a weird issue. The timezone which is provided in the ical file is being recognized but the the output of the time is adjusted to the timezone of the system executing the program. I will check the possibility to add a attribute in the setup to select the output timezone. The issue appears because I am testing on a machine which is configured with GMT+2 but the code is being executed on a sever running with GMT and all the times are shifted by 2 hours.