[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] icaldir Proposal
From:       "David Jarvie" <lists () astrojar ! org ! uk>
Date:       2006-02-08 13:09:25
Message-ID: GiR1jD.A.qNC.m8e6DB () s1 ! uklinux ! net
[Download RAW message or body]

On Wednesday 8 February 2006 5:57, Mark Bucciarelli wrote:
> I've been doing a little more hacking on the icaldir spec, trying to
finish it
> off.  See http://pim.kde.org/development/meetings/osnabrueck4/icaldir.php
for
>current version.
> 
> Way back when, on Wed, Oct 19, 2005 at 10:54:31PM +0200, Reinhold
Kainhofer wrote:
> > But you're missing
> > PRODID:-//K Desktop Environment//NONSGML KOrganizer 3.3//EN
> > VERSION:2.0
> 
> PRODID is interesting if many apps are editing the same file.   According
to
> the RFC, whoever created it first wins, but the utility of that is
> questionable.  It might be better to use this to identify the icaldir
version.

I want the application name and version to remain in the PRODID. If you want
to put the icaldir version in PRODID as well, I don't mind. Currently KAlarm
uses the PRODID string to distinguish KAlarm calendars from other ones, and
to identify which version of KAlarm wrote the calendar. This is necessary
because it uses various special property values to hold alarm attributes. It
needs to know which version of KAlarm wrote the calendar so that it can
provide backward compatibility. The KAlarm version is of course independent
of the ical version.

> Anyway, this is fixed in spec.
> 
> > One question that isn't answered: Where should the VTIMEZONE objects be 
> > stored? 
> >
> >  a) In each event? Then we would have lots of duplicated information as
most 
> > objects would use the same timezones
> >  b) separately and the events would just reference the TZID? Then they
(1) 
> > need to be stored in a separate directory and (2) all such vtimezone
objects 
>> need to be in memory so that when loading an event/todo you can find the 
> > correct time zone object, which is indicated only by the TZID (which is
not 
> > necessarily a globally unique ID...)
> 
> I think the tz database [1] that comes with UNIX is good enough
specification
> of timezone data, and that icaldir should simply reuse the tz database
codes;
> for example, TZID=America/New York.
> 
> In fact, after going back to read the RFC, I see it mentions the Olson
tzdb
> specifcally when it talks about a "time zone registry."
>
>   
>     The presence of the SOLIDUS character (US-ASCII decimal 47) as a
prefix,
>     indicates that this TZID represents a unique ID in a globally defined
time
>     zone registry (when such registry is defined).
>   
>     
>   
>     Note: The specification of a global time zone registry is not
addressed by
>     this document and is left for future study.  However, implementers may
find
>    the Olson time zone database [TZ] a useful reference. It is an
informal,
>     public-domain collection of time zone information, which is currently
being
>     maintained by volunteer Internet participants, and is used in several
>     operating systems. This database contains current and historical time
zone
>     information for a wide variety of locations around the globe; it
provides a
>     time zone identifier for every unique time zone rule set in actual use
since
>     1970, with historical data going back to the introduction of standard
time.
>   
>
> I belive this handles both of the issues you raise.

I'm sceptical about using the tz database and ignoring VTIMEZONE objects.
There is no guarantee that a VTIMEZONE imported from another system will use
an identical definition of the time zone to that held in the tz database.
Any discrepancies could result in wrong event times, etc. Until such time as
the ical spec says that the tz database is the only permissible source of
time zone definitions, and therefore scraps the VTIMEZONE object, we can't
just ignore VTIMEZONE. At least, not in calendars imported from elsewhere.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html

_______________________________________________
kde-pim mailing list
kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
kde-pim home page at http://pim.kde.org/
[prev in list] [next in list] [prev in thread] [next in thread]