Wrong time imported about ical_to_gcal_sync

[andrewramsay]

Event 'Event name' begin:2020-08-19T15:15:00+00:00 end:2020-08-19T16:15:00+00:00

That's the output directly from the ics module, right? It looks like it has had some timezone handling issues in the past but if I try a barebones test like this:

import ics

CAL = r'''
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//nothing//nothing
BEGIN:VEVENT
DTSTAMP:20200818T155617Z
UID:20200818T155617Z-someuid
DTSTART;TZID=GMT Standard Time:20200819T151500
DTEND;TZID=GMT Standard Time:20200819T161500
DESCRIPTION:test
END:VEVENT
END:VCALENDAR'''

cal = ics.Calendar(CAL)
print(cal.events)

then it prints:

<Event 'test' begin:2020-08-19T15:15:00+01:00 end:2020-08-19T16:15:00+01:00>

which looks correct. Not sure why it would be acting differently for you! Are you using ics v0.7? Does your ics file contain a VTIMEZONE definition for "GMT Standard Time" that might be causing ics.py to parse it in a different way?

[eev2]

Hi. Thanks for investigating.

That's the output directly from the ics module, right?

Yes, that's right.

I get a different result from you:
{<Event begin:2020-08-19T15:15:00+00:00 end:2020-08-19T16:15:00+00:00>}

I checked the versions of some of the packages I am using and they are the same as in your requirements:

>>> ics.__version__
'0.7'
>>> dateutil.__version__
'2.8.1'
>>> pytz.__version__
'2019.3'

Are there any other packages that I should check?

[eev2]

I also looked into the icalevents package:

>>> from icalevents.icalevents import events
>>> cal = events(file="test.ics")
>>> cal[0].start.hour
14
>>> cal[0].start.tzinfo
tzutc()

The test.ics file contains the ics data from your earlier message. It looks like this reads the time correctly since 14h UTC corresponds to 15h GMT+1.

[andrewramsay]

Definitely something weird going on here.

When I first tried that minimal example I ran it on a Windows system with a couple of different Python 3.x versions and got the same output each time. After seeing you were getting different results I thought to try another OS. On two different Linux systems I'm getting the same result as you with the timezone info stripped out!

So, I guess we have some kind of OS-dependent bug in ics.py here. I did a quick test with the latest 0.8-dev version and it still seems to end up parsing the same way on each OS so it doesn't look like it is specific to v0.7.

I'll have more time to look at this properly tomorrow and will try to figure out if it's a known issue. Hopefully there is some sort of simple fix.

[eev2]

I also use linux.
I just want to say that as a workaround I replace "TZID=GMT Standard Time" with "TZID=Europe/London" in the calendar data before parsing with ics which fixes the issue.

[andrewramsay]

After a bit of poking around, what seems to be happening is that the dateutil module just doesn't know what to do with the "GMT Standard Time" zone ID on a non-Windows system. If you are running Windows there's a separate dateutil submodule which contains a whole list of these "___ Standard Time" zone IDs, but it's only available on that platform.

The problem in this specific case with ics v0.7 is when it tries to use gettz here - tz is "GMT Standard Time" and since dateutil doesn't recognise that string, selected_tz is set to None and it falls back on UTC.

If you're happy swapping to "Europe/London" as a temporary fix that's good, I was going to suggest the same thing.

I also had a look at how icalevents/icalendar handle this. Turns out they simply have a file mapping the Windows IDs to regular ones which is used if a first attempt at parsing fails.

I'll see about swapping out ics.py in favour of icalevents, but it'll likely be a couple of days before I get that done.

[andrewramsay]

Turned out to be more work than I'd hoped to swap out one iCal module for another, but there's now a branch called change_ical_api using icalevents that seems to be working for me. Let me know if you run into any issues with it.

[eev2]

I tried it. I had to fix some indentation errors. It only syncs events from the current month and it deleted existing events from future months even though ICAL_DAYS_TO_SYNC = 0.

[andrewramsay]

Where were the indentation errors?? Don't know how I managed to introduce any of those!

I think the other issue is because icalevents seems to default to querying only 1 week ahead if you don't explicitly give it starting and ending dates. For example if you also import "date" from datetime and then change:

cal = events(ICAL_FEED)

to

cal = events(ICAL_FEED, end=date(2021, 1, 1))

that should cause it to include events up to Jan 1st next year.

I forgot to handle that part because the feed I was testing with only had events in the next 4 or 5 days. Will need to add an extra setting in config.py to control the query span - would you just want a way to say "I want to include the next x days/months of events"?

[eev2]

Where were the indentation errors??

In the function get_current_events.

OK, I set up the end to datetime(2031,1,1) and it works. (You haven't imported date.)

would you just want a way to say "I want to include the next x days/months of events"?

I thought that was the point of ICAL_DAYS_TO_SYNC. I guess, if it is set to 0 or negative, then you could overwrite with some large number, say 5*365 and then set the end argument of events to datetime.now() + timedelta(ICAL_DAYS_TO_SYNC). It's up to you.

[andrewramsay]

In the function get_current_events.

Odd... will check it again but I had no problems and was using the same editor on the same system for all the changes I made, it should have been consistent!

I thought that was the point of ICAL_DAYS_TO_SYNC.

Yeah there's obviously some overlap there now since icalevents has this different approach to querying feeds. Annoyingly there doesn't seem to be any way to tell it to just parse everything without giving some sort of end date, so I'll probably do what you suggested.

[andrewramsay]

Didn't notice any problems running the icalevents version for the last week, so have just merged those changes in.

I've taken the default sync period to be a year, so if you want it to go 10 years ahead you'll need to set ICAL_DAYS_TO_SYNC appropriately (I found it took a lot longer to sync for that kind of timespan though if you have many recurring events).

Feel free to reopen this if anything else crops up!