A summary of sorts (was: Re: Why and when storing local time? (Re: Basic rationale of the KEP #2 design))
Georg C. F. Greve
greve at kolabsys.com
Thu Mar 31 18:16:19 CEST 2011
On Thursday 31 March 2011 15.49:08 Florian v. Samson wrote:
> Please provide a pointer to the DST switching dates of UTC:
I never said that UTC switches.
What I said is that local time is expressed in variable UTC offsets.
> Until then I stick to believe UTC == "UTCWND"
For UTC == UTCWND to hold true, the conversion to either one from local time
and back would have to be identical. But UTCWND was specifically defined to not
behave identically, as it is supposed to behave as if DST did not exist.
That is what I tried to explain in
Copying from there: Considering that 10:00 in Europe/Berlin
* in the winter translates to
* in the summer translates to
So any local time with DST regime maps to different times for UTC and UTCWND,
which means they are *not* identical, nor were they defined to be.
> 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
Exactly. So we need storage that preserves or at the very least allows us to
restore that user intent from the stored data.
> > 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.
No, actually, because older clients stored data in UTC.
As shown above, UTC != UTCWND, so clients will interpret data wrongly.
We agree that compatibility is a major issue.
Because the old client behaviour was broken due to format insufficiencies, one-
way compatibility is the best we can ultimately hope for. Older clients will
never correctly interpret a full set of newer data regardless of which
solution we choose.
So the best we can do is a solution where newer clients will read and
interpret older data correctly. Because the old format is a very limited
subset of RFC3339, local time storage in RFC3339 fits that bill.
UTCWND on the other hand has no compatibility in either direction.
> > It can also not be stored as RFC3339, as that explicitly specifies UTC.
> So let it be it Zulu-time (UTC).
As explained before, that requires an additional point of metadata, namely
whether or not the client assumed that DST would be in effect for this
So it's UTC + TZ-ID + DST Assumption.
Clients would then have to adjust the stored UTC value accordingly if the DST
assumption turns out to be wrong. Some more work would have to go into this to
ensure that possible things like a changed base offset gets calculated
That is clearly a possibility, but much more complex than local time + TZ-ID.
> No, this is only correct for clients in the same time zone as the event
You misunderstood what I tried to say: Finding out what the user intended to
store requires zero steps when storing the intended local time.
That from there on you have multiple calculations to get to the end result is
correct, but also true for all other approaches.
> > 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.
Alright. As you may have seen, using static information as the primary source
of information is not shared by most people.
Would you be willing to live with a way to encode this format in KEP 2 as a
cache that is subordinate to the dynamic TZ-ID based lookup, but may be used
where such lookup is too hard and can be updated under certain conditions?
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format