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

[Florian v. Samson]

Georg,

Am Donnerstag, 31. März 2011 um 13:01:32 schrieb 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 

Please provide a pointer to the DST switching dates of UTC: I still (and 
Jeroen did sound similarly confused as I am) do not comprehend why you 
believe "pure UTC" switches to and from DST, thus one has to define a 
new "UTCWND" which does not switch.
Until then I stick to believe UTC == "UTCWND"

> as long as we know whether the user meant DST or standard time when 
> the event was stored, 

As discussed here numerous times: everybody usually thinks in local time, so 
that is what is meant, no matter if currently DST is active or not.  It is 
the duty of the client to normalise these timestamps before storing them in 
a Kolab-object, or to do nothing, if local time is stored directly, as you 
propose.

> but it adds one step to get to local time for all fields past, present 
> and future.  

Yes, but it can retain compatibility with older versions of the 
Kolab-format: a big pro, IMHO.
Storing local time implicitly breaks compatibility, and a mixed scheme adds 
complexity on top of that.

> It can also not be stored as RFC3339, as that explicitly specifies UTC.

So let it be it Zulu-time (UTC).

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

No, this is only correct for clients in the same time zone as the event 
itself; every other client has to do two transformations / time-conversions 
in order to calculate an event's time-dates in their local time: first 
calculate UTC, then the own local time.
So in the end the number of overall time-conversions is not substantially 
different, no matter if UTC or local time is stored.  Hence under this 
aspect storing local time or UTC are similarly laborious.

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

I did and still do, in case you forgot.  An I still believe it should be the 
primary source of TZ-data for the Clients accessing that Kolab-object, and 
the rules to dynamically update that in-format TZ-data should be well 
defined.

Florian