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

Bernhard Reiter bernhard at intevation.de
Thu Nov 18 22:26:53 CET 2010


On Wednesday 17 November 2010 14:58:08 Georg C. F. Greve wrote:
> > Where are DST information stored? Is this information read from an
> > external  source or is it stored inside the kolab format?
>
> DST information should not be stored in the format, because it is subject
> to change.

I've been thinking this back and forth during the last days
and my current state of mind is that adding the timezone information
to the object is slightly better. Let me try to explain:
We all agree that the definition of one timezone will change in the future.

> 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.

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 redundent 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.

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Germany Coordinator: fsfeurope.org. Coordinator: Kolab-Konsortium.com.
Intevation GmbH, Neuer Graben 17, Osnabrück, DE; AG Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

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


More information about the format mailing list