Collision on TZID with short timezone names

[schlatterbeck]

Quick Summary
Three letter timezone names are not internationally standardized. Using them as TZID will produce collisions.

Context

• vObject version 0.9.9 PRODID:-//PYVOBJECT//NONSGML Version 0.9.9//EN (installed via pip, Debian ships an older version)
• Python version 3.13
• Operating system and version: Debian 13.1 aka Trixie

Description
Take for example the time zone of Tel Aviv called 'Israel Standard Time' abbreviated IST and the time zone of Calcutta, 'Indian Standard Time' also abbreviated IST. Both timezones are, of course, different. When vobject encounters both, it will still use 'IST' as the TZID but use only one of the time zones whatever is encountered first. So using the short timezone name as TZID is a bug.

To Reproduce

import vobject
import datetime
from zoneinfo import ZoneInfo
 
cal = vobject.iCalendar ()
vev = cal.add ('vevent')
tz1 = ZoneInfo ('Asia/Kolkata')
tz2 = ZoneInfo ('Asia/Tel_Aviv')
vev.add ('dtstart').value = datetime.datetime (2025, 8, 7, tzinfo = tz1)
vev.add ('dtend').value = datetime.datetime (2025, 8, 7, tzinfo = tz2)
vev.add ('uid').value = 'Sample UID'
print (cal.serialize ())

results in

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 0.9.9//EN
BEGIN:VTIMEZONE
TZID:IST
BEGIN:STANDARD
DTSTART:20000101T000000
RRULE:FREQ=YEARLY;BYMONTH=1
TZNAME:IST
TZOFFSETFROM:+0530
TZOFFSETTO:+0530
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:Sample UID
DTSTART;TZID=IST:20250807T000000
DTEND;TZID=IST:20250807T000000
DTSTAMP:20250908T174548Z
END:VEVENT
END:VCALENDAR

The Israel 'IST' timezone is missing in this example.
When exchanging tz1 and tz2 it's the other way round (the indian tz is much simpler so I chose this as tz1 to make the example shorter)

[schlatterbeck]

At least in the linux version of python3.13 the ZoneInfo object has an attribute 'key' that suggests it is unique. May I suggest to use that for the TZID? That would be 'Asia/Kolkata' and 'Asia/Tel_Aviv' in the example given. I don't know what that would be on Windows, though.

[da4089]

Thanks for the report.

At first glance, this looks like a problem of using the TZNAME (not guaranteed to be unique) as the TZID (required to be unique).

The base problem is that the datetime.tzinfo API doesn't require its implementers to provide a unique identifier.

zoneinfo uses key(), pytz uses tzid() (or perhaps zone()), etc. See pickTzid() in icalendar.py.

For some reason, it appears that we're not checking for zoneinfo's key() function, and so we're falling back to tzname, which is causing the problem.

I should be able to get that patched tonight.

[da4089]

Are you able to test that path @schlatterbeck? I'm fairly sure it will fix this issue, but it'd be good to be sure.

If it works, I'll try to push a 0.9.10 release, and see if I can convince the Debian packager to adopt it.

[schlatterbeck]

Works like a charm. This was really a quick fix!

Note that I have troubles installing directly from version 265020d, I wasn't able to build a wheel (using python -m build) but I was able to run setup.py build which yielded something I could test with.
Let me know when you've pushed it.

Note that debian will probably not upgrade the stable (aka trixie) distribution, they still ship an old version 0.9.8 with trixie.