UTC timezone identification is broken

[Tobias Brox]

This is a continuation of the issue #333.

Somewhere in the code, while messing with the debugger, I saw something looking a bit like this:

if tz is not pytz.utc:
    (...)

Probably this is the reason why I in #333 was able to generate this output:

DTSTART;TZID=UTC;VALUE=DATE-TIME:20211117T150915Z

While the expected results should have been just this:

DTSTART;VALUE=DATE-TIME:20211117T150915Z

The extra "UTC" is probably not a big issue, it's probably not a breach of the standards and it will probably not break anything - so this is clearly a low-priority issue.

Here is the likely culprit:

$ git grep -n 'is not pytz.utc'
src/icalendar/prop.py:308:            if tzinfo is not pytz.utc and\

[Tobias Brox]

Simple Stupid Test code:

import datetime
import icalendar
import pytz
from zoneinfo import ZoneInfo
from dateutil import tz

utc1 = pytz.utc
utc2 = ZoneInfo('UTC')
utc3 = pytz.timezone('UTC')
utc4 = tz.UTC
utc5 = tz.gettz('UTC')

for tz in (utc1, utc2, utc3, utc4, utc5):
    myevent = icalendar.Event()
    myevent.add('dtstart', datetime.datetime.now().astimezone(tz))
    print(myevent.to_ical().decode('ASCII'))

With icalendar 3.9, utc2 and utc5 gives the undesired output. With my latest patch, it gives the correct output.

[Tobias Brox]

I can eventually make a proper pull request with test code and everything, but only after #334 is merged :-)

[Alex Peters]

Same problem when client code uses datetime.timezone.utc: rendered DATE-TIME components don't reliably get a Z at the end of their value (or perhaps more strangely, they do for DTSTAMP properties but not for DTSTART ones).

The interim workaround is to ensure that all datetime instances used by icalendar use the pytz.utc timezone specifically.

[Tobias Brox]

I lost the overview a bit, but I believe this issue was fixed in #339

[Nicco Kunzmann]

I added #387 to make sure...

[Alex Peters]

Thank you for your attention to this issue. Although it has been marked as low-priority, this actually breaks Google Calendar for me so I'm pleased to see progress nonetheless.

v4.1.0 has been released to PyPI but there's no corresponding section in the changelog at this time. Is this likely to have made it into the v4.1.0 release?

[Christian Geier]

No, it hasn't made it into v4.1. If somebody wants to back port the patch into the v4.x branch I'm happy to have a look at it.

#339 seems to be the relevant fix.

[Christian Geier]

@niccokunzmann should we aim at backporting some of these bugfixes or rather at pushing out a v5.0 release rather soon?

[Nicco Kunzmann]

@niccokunzmann should we aim at backporting some of these bugfixes or rather at pushing out a v5.0 release rather soon?

Our README is the guide:

We expect the master branch with versions 5+ receive the latest updates and features, and the 4.x branch the subset of security and bug fixes only.

So, this is a bug fix, I think, and so "should" be ported to the 4.x branch. I do not do that myself though... PR welcome!
I think, a label would be good..... How about needs 4.x PR, too?