A summary of sorts (was: Re: Why and when storing local time? (Re: Basic rationale of the KEP #2 design))

[Georg C. F. Greve]

On Wednesday 30 March 2011 19.06:50 Jeroen van Meeuwen (Kolab Systems) wrote:
> You can't use baseline offsets one way and then completely ignore the fact
> you  are supposed to use baseline offsets the other way around, too.

The point Bernhard was getting at, I believe, is that baseline offsets are not 
what are needed to calculate the behaviour as it was intended by the user.

For that, we need to know the local time the user meant to specify.

That can be retrieved from UTCWND as long as we know whether the user meant 
DST or standard time when the event was stored, but it adds one step to get to 
UTC as well as local time for all fields past, present and future. It can also 
not be stored as RFC3339, as that explicitly specifies UTC.

In my view this makes it inferior to pure UTC storage where that step is only 
required for getting the local time for future events.

But if local time is stored directly, the additional step disappears entirely.

If local time is also stored as RFC3339, it adds a slight redundancy, true.

So for events in the future we need to use TZ-ID to check whether the offset 
that was stored is still correct, and the local time will likely become the 
source for recurrence calculation.

On the other hand the huge advantage is that values are stored in direct and 
complete relation to UTC. For values in the present and past that relation is 
correct and values can therefore be used without additional processing, e.g. a 
script that just wants to sort all the events by their last modification date 
can just parse the datetime and use it as it is.

If we invent a new notation for storing local time, that is no longer possible 
as it will need mapping to UTC first.

To be honest I'm not convinced that avoiding a slight redundancy is worth such 
a complication for scripts and other "partial clients" that may want to make 
some secondary or tertiary use of Kolab data.

That is why right now I'm still seeing storage of local time as RFC3339 + TZ-
ID taken from the Olson database as the most sustainable approach.

The only open question I still have is whether or not a cache of the static 
rules which would also allow to handle ficticious time zones which VTIMEZONE 
allows is worth the complication and bloat.

Nobody seems willing to advocate for it strongly, so that may be seen as a 
reason to leave it away. But then there might be a use case that we are 
missing right now, and it might make life easier for client implementors on 
some platforms, perhaps, potentially at the cost of complicating everyone 
else's life.

So I'm really still wondering about this aspect.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110331/3aa1c1a0/attachment.sig>