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 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 
http://kolab.org/pipermail/kolab-format/2011-March/001287.html

Copying from there: Considering that 10:00 in Europe/Berlin

 * in the winter translates to
	 09:00 UTC 
	 09:00 UTCWND 

 * in the summer translates to
	 08:00 UTC
	 09:00 UTCWND

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

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

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

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 
> itself; 

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?

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/4a7a8139/attachment.sig>