Hint for exporting to Google Calendar

[rrthomas]

I just used Python icalendar to write a script to turn information from a custom calendaring sytem into an iCal file I could import into Google Calendar. It worked fine, but there was one wrinkle; I wonder whether it might be worth documenting since Google Calendar is presumably a fairly popular target:

I found that my VEVENTS needed a UID field, or Google Calendar gave an error. (To be precise, this was only a problem when I had more than one event, which is annoying in itself, as it made the problem harder to debug.)

This is not in RFC2445, of course, where the UID field is optional.

If you're interested and tell me where you'd like it I'd be happy to write a sentence for inclusion in the documentation.

[rrthomas]

Actually, it appears to be worse than that. After adding UIDs I can import up to 3 events, but not 4 (although e.g. 1-3 and 2-4 and 1,4 work, so it doesn't appear to be some clash between the events themselves). Hence closing for now, since I don't have a way to make it work.

[thet]

was the error on google somehow expressive or meaningful?
it would be good to have some anonymized test data. can you provide these .ics files or the steps to reproduce the problem?

[rrthomas]

No, the error was not expressive or meaningful, it was just a generic "error, zero events imported". The same file supplied as a URL worked fine. I tried uploading from a different browser, same problem. I'm baffled.

[thet]

please provide test data to reproduce the problem.

[rrthomas]

Here's some test data. If I upload the whole thing, I get an error "Error. Zero events processed." If I upload any two events, it works fine. If I serve the whole thing via HTTP, it works fine.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Reuben Thomas [email protected]//signup2ical//EN
BEGIN:VEVENT
SUMMARY:Foo
DTSTART;VALUE=DATE-TIME:20120107T100000Z
DTEND;VALUE=DATE-TIME:20120107T113000Z
DTSTAMP;VALUE=DATE-TIME:20140109T225137Z
UID:1610
END:VEVENT
BEGIN:VEVENT
SUMMARY:Foo
DTSTART;VALUE=DATE-TIME:20120108T094500Z
DTEND;VALUE=DATE-TIME:20120108T120000Z
DTSTAMP;VALUE=DATE-TIME:20140109T225137Z
UID:1611
END:VEVENT
BEGIN:VEVENT
SUMMARY:Foo
DTSTART;VALUE=DATE-TIME:20120108T150000Z
DTEND;VALUE=DATE-TIME:20120108T163000Z
DTSTAMP;VALUE=DATE-TIME:20140109T225137Z
UID:1612
END:VEVENT
END:VCALENDAR

[thet]

the uid is quite weak. regarding to the RFC, the UID must be a globally unique identifier ( http://tools.ietf.org/html/rfc5545#section-3.8.4.7 )
try using the UIDGenerator from https://github.com/collective/icalendar/blob/master/src/icalendar/tools.py
(example in https://github.com/collective/icalendar/blob/master/src/icalendar/tests/test_unit_tools.py )

maybe this solves the problem?

[rrthomas]

It doesn't help. The UID is an optional field, and if I remove it, it still doesn't work. (Originally I didn't have a UID field. I added it to see if it would help. I didn't see the spec that said it must be a GUID; thanks for pointing me to that.)

Also, as I said, when I serve the file via HTTP, it loads fine.

[rrthomas]

I've now got it working. Since Google's documentation is woefully inadequate, maybe it is worth documenting my findings in python-icalendar's docs.

The following findings are only tentative; without either considerable testing OR better documentation from Google, it's very hard to be sure of the facts.

1. UIDs seem to be required. (I used the standard Python module uuid's uuid4 function. When I did not use UUIDs, or used weak UIDs, Google only fetched the file once, according to server logs.)
2. The file must be on a low-latency server. (I could not successfully upload a file: I got an immediate error once the file was bigger than a handful of events. Similarly, when I hosted my iCal file on a high-latency home server, Google claimed it could not load the feed, though testing from across the net with wget was able to fetch the file with no problem.)

[elzibubble]

@rrthomas have you shared your script anywhere please? I'm using https://github.com/lxsli/add-vcal-to-google . The lack of TZ support is frustrating me (now DST has started) and if you've already cracked that nut I'd love to steal your code.

[rrthomas]

@lxsli, sorry, I would need permission to share my code; but I didn't have any problems with TZs, so I can tell you what I did: I simply hard-wired it, like this:

s['start'] = parse_time(s['start']).replace(tzinfo=timezone("Europe/London"))

This is possible for me because the calendaring system I'm working with is London-based, and includes only events happening in London, therefore the TZ is always the same; however, it does suggest that simply setting the TZ works.

[geier]

@lxsli you might want to have a look how we do it in khal at the moment, as long as you have no infinitely recurring events it seems to work well enough.

[elzibubble]

@rrthomas @geier thank you both for the responses! It turns out that upgrading to icalendar 3.9.0 has been a drop-in fix for me. I now get a correctly timezoned date from isoformat().

[Lx]

I guess Google Calendar's implementation may have changed since the last comment on this issue, but as of now, I can successfully import events without UIDs.