Repository: collective/icalendar

Issue #333: Some timezones breaks after migrating from pytz to zoneinfo
Created: 2021-11-16T23:37:12Z
I just encountered a strange issue when running tests in my calendar-cli project. In particular, it broke with the DeNoronha timestamp (according to a contributor of test code to the caldav library, this place is well-known for being a "remote place", so it's used as a "remote time zone" in the tests).  After migrating from pytz to zoneinfo the test code started breaking.
I wrote up the following code to highlight the breakage:
import datetime
import pytz
import zoneinfo
import icalendar

utc1 = pytz.utc
utc2 = zoneinfo.ZoneInfo('UTC')
oslo1 = pytz.timezone('Europe/Oslo')
oslo2 = zoneinfo.ZoneInfo('Europe/Oslo')
remote1 = pytz.timezone('Brazil/DeNoronha')
remote2 = zoneinfo.ZoneInfo('Brazil/DeNoronha')

for tz in (utc1, utc2, oslo1, oslo2, remote1, remote2):
    myevent = icalendar.Event()
    myevent.add('dtstart', datetime.datetime.now().astimezone(tz))
    print(myevent.to_ical().decode('ASCII'))
When running it, I get the following output:
BEGIN:VEVENT
DTSTART;VALUE=DATE-TIME:20211116T232629Z
END:VEVENT

BEGIN:VEVENT
DTSTART;TZID=UTC;VALUE=DATE-TIME:20211116T232629Z
END:VEVENT

BEGIN:VEVENT
DTSTART;TZID=Europe/Oslo;VALUE=DATE-TIME:20211117T002629
END:VEVENT

BEGIN:VEVENT
DTSTART;TZID=CET;VALUE=DATE-TIME:20211117T002629
END:VEVENT

BEGIN:VEVENT
DTSTART;TZID=Brazil/DeNoronha;VALUE=DATE-TIME:20211116T212629
END:VEVENT

BEGIN:VEVENT
DTSTART;TZID=-02;VALUE=DATE-TIME:20211116T212629
END:VEVENT

Note that for every time zone above, the output has changed simply from moving from pytz to zoneinfo.  I would expect there to be no changes in the output, and I think the pytz behaviour is correct:

for timestamp suffixed with Zulu,  no point to specify UTC.
The full name of the timezone should be given, and not the short name
In particular, "-02" is simply not an acceptable TZID.

Duplicate issue #272: Timezone encoded in DTSTART is ignored by other software
Created: 2018-10-03T21:27:20Z
Hi,
TLDR: Perhaps appending "Z" to DTSTART and DTEND would help in my case?
I end up with such event data that other software ignore the TZID part and event is displayed at incorrect time:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//andrey-utkin//taskdb//
BEGIN:VEVENT
SUMMARY:test event
DTSTART;TZID=+00;VALUE=DATE-TIME:20181003T211423
DTSTAMP;VALUE=DATE-TIME:20181003T211423Z
UID:e01b0878-2f0a-4c10-81f7-a9d972b4a88f
END:VEVENT
END:VCALENDAR

I upload this file to FastMail CalDAV server, where I use calendar data through Fastmail web UI, and through Android Calendar app. Both of them show the event time as if it was declared with "floating timezone", taking the time literally and not offsetting by timezone offset.
As I see, when FastMail creates an event in UTC timezone, it formats it like DTSTART:20181003T211423Z and it works properly.
I use a script https://github.com/andrey-utkin/taskdb/blob/master/bin/taskdb_cal_export
Say, being in PDT timezone at 14:14:23, I am creating an event scheduled for now. I store the current date in PostgreSQL "timestamp with time zone". postgresql.conf has timezone="UTC" so if I query the data, I get:
j=> select scheduled from tasks where uuid = 'e01b0878-2f0a-4c10-81f7-a9d972b4a88f';
           scheduled
-------------------------------
 2018-10-03 21:14:23.126289+00
(1 row)

Closing comment (2022-01-07T08:11:08Z): Came to think, this is a bit related to #333 as well.