timezone external or internal (Re: KEP 2: Modification of datetime type, introduction of 'tz' sub-tag)

[Bernhard Reiter]

Am Freitag, 19. November 2010 06:27:28 schrieb 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.

The Kolab Storage Format together with the Kolab Compliant Label that mandates 
some client behaviour has the chance to avoid this fragmentation and should 
try hard to do so. The prospect is good in my view because we deal with a 
Storage format and not with an interchange format like iCalender.
Overstated: We control the implementations for the storage as with an exchange 
format, we do not. 

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

Yes, I agree about the difficulty. Some sort of update mechanism is needed.

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

My first idea of an update mechanism would be: also save the Olson name
and the revision of the Olson database file. If a client has a newer revision,
it can suggest to update the description to the user. This only works of 
course, if it can be decided from the revision what is the newer file.
I have hoping that the Olson database provided something like this,
eyeballing the files, I saw something like a version number:
! # @(#)australasia     8.19

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

Good hints, I beleve that the timezone service might be an issue
with offline capable clients. They still would need to carry a full set
of the library around in case they look at data while they are offline.
The timezone-xml seems to want to exactely 
map the VTIMEZONE section of iCalender into XML. 
I cannot say if this is good or bad, it would of course inherit
all problems and strong sides of VTIMEZONE.

Bernhard

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht 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/20101214/7ead1098/attachment.sig>