#73: No way to specify timezone ----------------------+------------------------- Reporter: kparal | Owner: pingou Type: defect | Status: assigned Priority: major | Milestone: 0.4.0 Component: fedocal | Version: development Resolution: | Keywords: ----------------------+-------------------------
Comment (by kparal):
Hmm, so, I imported this into Evolution and I see the recurring meeting to happen 18:00-19:00 until Mar 24 and 17:00-18:00 since Mar 31. Which is incorrect, because I would like to pin this even to Czech (or US or whatever) local time, i.e. 18:00-19:00 no matter whether there is summer or winter time.
The reason is that you defined that even to happen always in CET timezone, but since Mar 30 there is CE'''S'''T in the Czech Republic. (However, all countries might not switch to CEST at the same time, or at all).
So, I think there are two options: 1. Define the events since Mar 31 in CEST instead of CET. However, you still need a country selector to decide when the summer time change occurs. (That's why the timezone is defined for "Prague" in Evolution export, I guess). 2. Use the Evolution way - define all the timezone switches for reasonable past and future years for all countries included in the calendar. Then create a simple recurring event using this timezone definition.
The option 1. includes a short timezone definition, but massive duplication or items representing the recurring events. The option 2. includes a lot of timezone definition boilerplate, but every (even recurring) event is then a simple non-duplicated item. With lots of events in the calendar, option 2. seems more efficient and simpler and I begin to understand why it is implemented this way in Evolution.
I tried to create a simple recurring event in Google Calendar and the output is even simpler: {{{ BEGIN:VCALENDAR PRODID:-//Google Inc//Google Calendar 70.9054//EN VERSION:2.0 CALSCALE:GREGORIAN METHOD:PUBLISH X-WR-CALNAME:test X-WR-TIMEZONE:Europe/Prague X-WR-CALDESC: BEGIN:VTIMEZONE TZID:Europe/Prague X-LIC-LOCATION:Europe/Prague BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU END:STANDARD END:VTIMEZONE BEGIN:VEVENT DTSTART;TZID=Europe/Prague:20140115T160000 DTEND;TZID=Europe/Prague:20140115T170000 RRULE:FREQ=WEEKLY;UNTIL=20140514T140000Z;BYDAY=WE DTSTAMP:20140114T111808Z UID:tbi08k9stmmfac5jrbe3v8nl2g@google.com CREATED:20140114T111705Z DESCRIPTION: LAST-MODIFIED:20140114T111705Z LOCATION: SEQUENCE:0 STATUS:CONFIRMED SUMMARY:foobar TRANSP:OPAQUE END:VEVENT END:VCALENDAR }}} I think the timezone definition is simple for Czech Republic because we had no changes in our history as for when the summer time change occurs. But in some other countries it might be different (they might have changed the date of summer time change somewhere in their past). Still, there would be probably maximum of two or three DST definitions, which is much shorter than the Evolution-generated madness :-)
Because fedocal is not about perfect accuracy of events two decades ago, I think you should go for the simplest solution available. Currently it seems "Google Calendar" way - provide a single simple definition of DST change (as seen above) for every country available and include the necessary ones to ical export. The events can then use this definition as their TZID.
The list of DST dates and their respective countries could be searchable from the Internet, or it could be extracted from Evolution. By the way, isn't there some library module in Evolution that could be used for DST handling, so that you don't need to implement it from scratch?