Automatically created VTIMEZONE doesn't cover old datetime (e.g. in DTSTART/DTEND)

[schlatterbeck]

Quick Summary
For an old appointment (from an old calendar) from before the year 2000 the generated VTIMEZONE does not match the datetime.

Context

• vObject version 1.0.0 with recent patch for TZID, see Collision on TZID with short timezone names #117
• Python version 3.13
• Operating system and version: Debian 13.1 aka Trixie

Description
When I have times in a VEVENT before the year 2000 the automatically generated VTIMEZONE starts 2000.
This is especially important for times before 1980 since in most european countries there was no daylight saving time before 1980 (unless you go back to the 1940s). The Unix/Linux timezone info has the full picture, so vobject should export this correctly depending on the used datetime(s).

To Reproduce

import vobject
import datetime
from zoneinfo import ZoneInfo
 
cal = vobject.iCalendar ()
vev = cal.add ('vevent')
tz  = ZoneInfo ('Europe/Vienna')
vev.add ('dtstart').value = datetime.datetime (1970, 1, 1, tzinfo = tz)
vev.add ('dtend').value = datetime.datetime (1970, 8, 7, tzinfo = tz)
vev.add ('uid').value = 'Sample UID'
print (cal.serialize ())

yields the following, observe that the DTSTART of the VTIMEZONE is in the year 2000 while the VEVENT is in 1970. In 1970 Europe/Vienna doesn't have daylight savings.

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//PYVOBJECT//NONSGML Version 0.9.9//EN
BEGIN:VTIMEZONE
TZID:Europe/Vienna
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:Sample UID
DTSTART;TZID=Europe/Vienna:19700101T000000
DTEND;TZID=Europe/Vienna:19700807T000000
DTSTAMP:20250910T172032Z
END:VEVENT
END:VCALENDAR

I would be quite happy if there is a way to do this manually -- in fact very old appointments might not be the common use-case.

[da4089]

I think the problem is in TimezoneComponent.settzinfo(), where the start and end parameter default values appear to control the extent of the RRULEs written in describing a VTIMEZONE.

I haven't looked at a good solution here: but a quick solution would likely be to change the default for start to, say 1900, instead of 2000. That should pick up enough history for most uses. I tested your example using 1960, which seemed to do the right thing.

I haven't yet looked at why it's done this way at all, but I assume there's no function to get the transition points via the datetime.tzinfo API.

[schlatterbeck]

Fine with me to just set this to an earlier time -- maybe not 1900 because this might clutter the timezone for many purposes, the 1940s have several experiments in different european countries. The iCalendar package uses 1970 (and they have the end time 2038, seems that package doesn't implement RRULE). Jan 1 1970 UTC also happens to be the start of UNIX time.

Maybe you can make the start time a user-defined setting? Better yet go over all the timestamps in the actual VEVENTs and take the lowest.

I also think the API doesn't have a method to get the transition points: Even the zoneinfo on Linux has a tool 'zdump' which has a -i option to print the transitions. It says in the manpage that you can construct artificial timezone settings where it will miss some transitions.

From the manpage of zdump:
"Time discontinuities are found by sampling the results returned by localtime(3) at twelve-hour intervals. This works in all real-world cases; one can construct artificial time zones for which this fails."