UnicodeEncodeError: 'ascii' codec can't encode character u'\xa0' in position 20: ordinal not in range(128) about ical_to_gcal_sync

[andrewramsay]

Will have a look at this but am travelling until the 23rd and only have a phone with me, so unlikely to be able to do much before then! In the meantime you could try commenting out that line, it's just logging by the looks of it. Might work ok without trying to print whatever the problematic characters are.

[adambarnett52]

Ok, no problem, much appreciated

…

On Mon, Dec 16, 2019 at 12:45 PM Andrew Ramsay ***@***.***> wrote: Will have a look at this but am travelling until the 23rd and only have a phone with me, so unlikely to be able to do much before then! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7?email_source=notifications&email_token=ABKXAE4ZZVIMYCPG73TMEELQY5Z5TA5CNFSM4J3IAS42YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEG6SZNY#issuecomment-566045879>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKXAE4YLRFGCBQ2LFPNF3DQY5Z5TANCNFSM4J3IAS4Q> .

-- Adam Barnett

[andrewramsay]

u\xa0 is the Unicode "non-breaking space" character, I guess this might be an event name originally pasted from a browser or Word or some other rich-text source?

Anyway, do you happen to be using Python 2? I was trying to reproduce this but couldn't until I thought to try Python 2 instead of Python 3.5 as I have on my RPi. It seems like only Python 2 throws up errors like this (also when deleting an event with non-ascii characters), Python 3 doesn't complain at all so I guess some of the many string-handling updates from 2->3 are responsible.

If you can easily update your copy to run with Python 3.x I think it will fix this. I just realised I haven't noted in the README that I've only tested the script with 3.x, so I'll do that soon.

[adambarnett52]

Ah yes. It’s python 2.7 Not sure I can upgrade. But might be able to run in a virtenv

…

Sent from my iPhone

On 23 Dec 2019, at 13:07, Andrew Ramsay ***@***.***> wrote:  u\xa0 is the Unicode "non-breaking space" character, I guess this might be an event name originally pasted from a browser or Word or some other rich-text source? Anyway, do you happen to be using Python 2? I was trying to reproduce this but couldn't until I thought to try Python 2 instead of Python 3.5 as I have on my RPi. It seems like only Python 2 throws up errors like this (also when deleting an event with non-ascii characters), Python 3 doesn't complain at all so I guess some of the many string-handling updates from 2->3 are responsible. If you can easily update your copy to run with Python 3.x I think it will fix this. I just realised I haven't noted in the README that I've only tested the script with 3.x, so I'll do that soon. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[andrewramsay]

When I get a chance I'll try to fix the 2.7 issue in a way that still works with 3.x, shouldn't be too difficult

[andrewramsay]

If you want to stick with Python 2.7, try the unicodefix branch I just created. The changes are minimal but I think they should prevent these issues with event names cropping up without affecting Python 3.x.

Let me know how it goes, if it seems OK I'll merge it back to the master branch.

[adambarnett52]

seems to work correctly, thanks
Any suggestion on how to avoid 403 errors, when makes too many requests
I am sycing 3 cals to gsuite, is there a way to just do the next 24 hours of events ?

[andrewramsay]

seems to work correctly, thanks

Good, will merge that branch back in then.

Any suggestion on how to avoid 403 errors, when makes too many requests
I am sycing 3 cals to gsuite, is there a way to just do the next 24 hours of events ?

How are you scheduling them? Just running the script 3 times consecutively? You might be able to work around it to some extent by:

1. Scheduling each individual sync at longer intervals (maybe an hour apart?)
2. Increasing the API_SLEEP_TIME value in config.py, which will reduce the rate of API requests the script submits at the cost of making each run take longer.

At some point next week I can look into adding an optional filter to be applied to the initial collection of iCal events. That would allow for removing anything >24 hours ahead, as well as other criteria like "only include events with some string in their name".

[adambarnett52]

Hi,

{quote}
How are you scheduling them? Just running the script 3 times consecutively? You might be able to work around it to some extent by:
{quote}
Yes a jenkins job. I will up the timeout

{quote}
At some point next week I can look into adding an optional filter to be applied to the initial collection of iCal events. That would allow for removing anything >24 hours ahead, as well as other criteria like "only include events with some string in their name
{quote}
Sounds good, i guess i only really care about the next 24 hours ( or todays events ) if that makes it easier. The reason is that i am syn'ing from an ical into gsuite for Zoom to pick up the data and Zoom only shows one days worth of events on its display

[andrewramsay]

OK, I'll just keep it simple in that case: try the filterevents branch I've just pushed. There's a new value in config.py called ICAL_DAYS_TO_SYNC. The default is 0 which preserves the current behaviour, but if you set it to 1 it should filter out events retrieved from the iCal feed with dates >= 1 day in the future. Only tested it briefly but it seemed to work for me.

[adambarnett52]

Perfect, worked like a charm