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

Shawn Walker swalker at bynari.net
Thu Nov 18 22:40:17 CET 2010



On 11/18/2010 3:26 PM, Bernhard Reiter wrote:
> 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.

If there is going to be a timezone definition in the Kolab spec, I think it would be better to not
support the Olsen database.  I understand that the Olsen database can be updated when the
daylight/standard date/time has been changed.  The client should use the timezone definition the way
the iCal TIMEZONE definition is defined that the client will be able to determine timezone information.

Windows by default does not use Olsen database, so if we can have the timezone definition in the
that has all of the offsets for daylight/standard, that would help the client to be able to know
what the time was created in the timezone.

> 
>> 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.
> 
> 
> 
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Shawn Walker
Senior Software Developer
swalker at bynari.net
Bynari, Inc.
222 W Las Colinas Blvd, Suite 1320N
Irving, TX  75039
http://www.bynari.net
(800) 241-1086
(214) 350-5772 X29
(214) 352-3530 fax




More information about the format mailing list