KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

[Andrew McMillan]

On Thu, 2010-11-18 at 22:26 +0100, Bernhard Reiter wrote:
> 
> > But all operating systems that are capable of running Kolab
> > clients have timezone information and libraries available which can provide
> > this mapping, and are kept up to date by the distributions themselves, so
> > changes would be handled correctly in the future.
> 
> Unless we define a specific versions of the Olson database to be used 
> for a specific timeframe, several clients will have different versions.
> This would mean a client with a new database and one with an old one, e.g. 
> because of long term support would display events at different times.
> 
> I believe it is better to have a self contained definition. If we would 
> add the information when the timezone changes are to the format than
> all clients would display the information at the right time.

iCalendar went down this path, and I think it offers mixed results. Many
modern clients work hard to ignore the payload of timezone information
in iCalendar trying to use it as a clue to guess which of the timezones
in the client's (or client OS) to use.  I believe they do this because
it has proved an unreliable source of data, and each client developer
hopes their data source is likely to be more up-to-date than the
information contained in an event.

In particular it becomes problematic for long-running events which were
scheduled some years back, before the DST dates for the current year
were even tabled as legislation.  When multiple definitions for a
timezone are available it can also be difficult to choose which one is
correct, regardless of last-modified timestamps on them which seem not
to be trustable, sometimes being initialised with the date on which the
underlying timezone definition changed, sometimes initialised with the
date on which this particular instance of the data was generated, and
sometimes initialied with the date on which this version of the Olson
database was released.

I personally tend towards a hope that a standard timezone services will
become more widely available in the coming few years, offering some
possibility that a simple timezone identifier will be possible.  If that
day arrives I believe it is expected that iCalendar will redefine the
VTIMEZONE component to allow stub definitions.

In light of this history and activity it is probably worth reviewing the
following proposals currently grinding through the IETF process to see
if any use can be made of their work:

http://tools.ietf.org/html/draft-douglass-timezone-service/

http://tools.ietf.org/html/draft-douglass-timezone-xml


> Clients then SHOULD compare the timezone definition to its own
> definition of the same timezone and SHOULD offer the user a way
> to update if there is a missmatch. For this I'd propose
> to have another <timezonename> tag or so in there, which is redundant MUST not
> be considered for calculation of the events. Only the timezone definition 
> itself should be considered.
> 
> A minor advantage would be that client were not required to have a full set of
> the Olson database on board (which some systems do not have I believe). It is 
> not much space, but hey. ;)
> I believe the extra space is not an issue as this info would only be added
> to events that recurr and not for single events.
> 
> > The referenced Olson database seems the best and most canonical resource
> > for this across all systems that we could find. It is certainly present on
> > all GNU/Linux systems, which are the ones that Evolution would be running
> > on.
> 
> I've also heard that it is a good reference database.

Olson has indicated that he is retiring, and I understand that the
maintenance of the database is being taken over by a team of people.  I
believe it is hoped that some improvements in the timeliness of updates
can be made, along with an increase in the 'official'-ness of the data.

Cheers,
					Andrew.

-- 
------------------------------------------------------------------------
http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
Twitter: _karora                                  Phone: +64(272)DEBIAN
              Does the turtle move for you?  www.kame.net
------------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.kolab.org/pipermail/format/attachments/20101119/8ef3b490/attachment.sig>