Don't use datetime.utcnow().

[smurfix]

Deprecated since Python 3.12.

[smurfix]

NB it might be helpful to tell pytest to turn warnings into errors by default.

[tobixen]

As for now, I think it's not possible, i.e. we get warnings due to server incompatibility workarounds.

[tobixen]

The changeset looks good, but I think it will have to wait some few years as datetime.UTC apparently does not exist in older python versions.

[smurfix]

I think it will have to wait some few years as datetime.UTC apparently does not exist in older python versions.

You're right, it's only available since 3.11. But we can easily wrap it in an exception handler and use the old way if UTC doesn't exist.

However, the old code is completely wrong anyway. To demonstrate:

>>> import datetime as dt
>>> dt.datetime.utcnow().astimezone(dt.timezone.utc)
<stdin>:1: DeprecationWarning: datetime.datetime.utcnow() is deprecated and scheduled for removal in a future version. Use timezone-aware objects to represent datetimes in UTC: datetime.datetime.now(datetime.UTC).
datetime.datetime(2024, 10, 11, 11, 36, 5, 797930, tzinfo=datetime.timezone.utc)
>>> dt.datetime.now(dt.timezone.utc)
datetime.datetime(2024, 10, 11, 13, 36, 18, 566646, tzinfo=datetime.timezone.utc)
>>> dt.datetime.now()
datetime.datetime(2024, 10, 11, 15, 36, 30, 34961)
>>>

The first result is bogus because right now it's 15:36 local time and I'm in timezone T+0200, thus UTC is 13:36.

I pushed a fix that replaces UTC with timezone.utc which should be stable enough.

[tobixen]

Weird, the test for 3.7 and 3.9 passes now, but the test for 3.8 fails consistently (I tried rerunning it in case it was just some temporarily fluke). I also reran the test for 3.12 just in case a new version of the icalendar library was released just while the tests were running. I didn't look into why the test is breaking yet.