RFC: addition of generic timezone support to kdelibs

[Reinhold Kainhofer]

Shaheed wrote:

> Reinhold wrote:
> 
>>> There is also a mini-timezone database in
>>> kdepim/libkcal/libical/zoneinfo which I have not really looked at.
>>
>>These are the snipplets of the VTIMEZONE objects that come with libical.
>>If (and we really need to, sooner rather than later, since that's an
>>absolute requirement to be compatible with other groupware systems) we
>>implement proper time zone support in libkcal, we need to have the
>>iCalendar VTIMEZONE object available for each time zone to copy it to the
>>.ics files. Now the problem is that this means that in libkcal we won't be
>>able to use the system-wide time zone library, but need our own
>>timezones... (Unless the KTimezone class is able to give a full
>>representation of the timezone information needed for the Calendar format,
>>in particular, we need all date/times when DST starts/ends, and the offset
>>to UTC for DST and normal time periods).
> 
> Well, if you look at ktimezones.cpp, you'll see it contains a complete
> lexical analyser for zoneinfo files at the bottom of the file. Using that,
> it would not be hard to flesh out the KTimezone class with accessors for
> this information.

Okay. Looking at the class, what I'm missing are
1) Finding the offset to UTC at any time (not just at the current date/time)
2) Being able to convert a QDateTime from one KTimezone to another
3) Ability to add custom time zones (if you get an invitation with a VTIMEZONE 
object, it doesn't necessarily match a time zone object that is available 
locally).

> If we could work out what kind of API would be useful, I'd certainly be
> wiling to give that a shot. I'd be worried about doing it without such
> input though.

Okay, let's look at a sample time zone in iCalendar format:
kdepim/libkcal/libical/zoneinfo/Europe/Vienna.ics

If you create an event in korganizer in that timezone, this VTIMEZONE object 
needs to be inserted into the .ics file. It consists of daylight parts and 
standard parts. E.g.
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT

This means that on March 29, 1981, daylight saving time starts (which means 
the new UTC offset is +2 hours, before it was +1 hour), the name of the new 
time is CEST, and this change happens every year on the last sunday in march.

Similarly, for the switch back to standard time:
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD

Instead of the RRULE, it's also possible to give explicit dates when dst or 
standard time starts (in particular that's needed for years before the switch 
was regulated by law to follow a simple rule. E.g. in Sweden or Denmark the 
dst start/end was not in line with the rest of Europe until 1996 or 97, but 
followed its own rules.)


Now, when you receive an .ics file, you need to use the VTIMEZONE object from 
that file to convert the times from the timezone of the file to your local 
timezone. That's where my requirements 2) and 3) from above comes into play.

Cheers,
Reinhold


-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050706/f24644a7/attachment.sig>