Rationale of the KEP2 design: central in-format TZ-data vs. individual local TZ-databases and more (Part 2)

[Georg C. F. Greve]

Dear Florian,

On Tuesday 15 March 2011 14.01:52 Florian v. Samson wrote:
> > There are two ways of encoding DST data.
> Oh, I can envision many more ...

In that case I would appreciate your explaining them to us.

Thus far, including in your email, there have been two approaches: static and 
dynamic through a data base.


> > One is to encode it statically, e.g. this time zone always switches to
> > summer time on 3rd of March every year and back on the 5th of October.
 > ... but this one would be simply idiotic.

It is nonetheless the one you seem to propose to use:

> No, the source of the TZ-data is completely unrelated to its properties!
> So a database is just one possible source of that TZ-data, exactly the same
> things can be achieved with in-format TZ-data (i.e. the Kolab-objects
> containing the TZ-data),

with the difference that you seem to propose updates of that static data:

> e.g. updates, changes in the TZ-data (= the TZ-definition), etc.

You do not however explain where you think those updates would come from.

The normal approach would be to use the system-wide database, but you rejected 
its usage. So my question would be: From which source do you obtain updates?

Also, the question would be: How would they be propagated in a safe and solid 
way, as we have no way to update them for cases where invitations have been 
sent and accepted, for instance, or where clients do not have write access, or 
how do you prevent editing wars between clients who both "know better"?

In either case: If you store ONLY static data, how do the clients know which 
time zone to update the entires for? And if you store both TZ-ID and static, 
which of them is authoritative, and how do you enforce that?

As explained before, iCalendar has failed at exactly that point, because it is 
a redundancy, and (upon changes in the DST regimes) contradiction within the 
stored data.

The only way I could see to resolve this would be to declare the static 
encoding a mere "cache" for clients that do not have capability to access a tz 
database, although those clients would also have a substantial number of other 
issues, as the need to translate between time zones for display based upon the 
user's preference is unlikely to disappear.

So the questions here are: 

 - What kind of client would not necessarily have a TZ database on board?

 - What would be gained by the cache?

 - Or would the cache merely complicate and bloat the format?


> How can one possibly take something into account, which one cannot possibly
> be aware?

I've made you aware of these points, and the people concerned are on this 
list, so could easily state if they felt misrepresented. Your accusations that 
I would falsify and lie about what people tell me are however entirely 
inacceptable and inadequate to a professional conversation.

Your postings in this thread have often come close to ad-hominem attacks, and 
may at times have been read as such. I strongly suggest you moderate your tone 
in a way that befits a professional discussion.

Forthermore, as explained before your suggestion to forbid or ignore all 
personal discussions between people about topics that are being discussed on 
this list is unrealistic in my view and will lead to less, not more engagement 
with the process.



> I did and it does not change the fact, that you and/or Jeroen initially
> proposed RFC3339. Hendick's mail you quoted was amidst the intense RFC3339
> discussion and is quite ripped out of context the way you present it, IMO.

Hendrik made the proposal to use RFC3339 for local time storage in the spirit 
of compromise to achieve a consensus that everyone could live with, and in 
fact welcomed the final outcome.

That he was not the original source of this suggestion does not change the 
fact that he suggested this in a cooperative and forward looking way, as 
Jeroen then accepted use of storage in local time, which was initially the 
idea of Hendrik.

So there were aspects of each of the contributors in the final KEP, and while 
neither got their preferred solution, everyone realized that the result was 
technically sound and would allow them implementation.

It is rather unfortunate that this consensus has then been derailed, in 
particular as these contributions so far did not yet add technologically 
substantive contributions to the debate.


> The only, but vast difference is that "UTC + TZ" is compatible to the
> Kolab-Format, but "Local Time + TZ" is not!
> Any additional ambiguity you sensed in "UTC + TZ" over "Local Time + TZ"
> does not exist (or I just do not see it).

As explained in 

	http://kolab.org/pipermail/kolab-format/2010-December/001178.html
 
UTC + TZ requires knowledge about the DST assumption of the client that made 
the appointment. You need to know whether that client assumed that DST would 
be in effect at that date, and whether it was correct, otherwise you do not 
know whether its calculation of intended local time to UTC was correct.

So at the very least, you need "UTC + TZ + ASSUMPTION".

That is why Jeroen for instance suggested to eliminate the assumption by 
always storing "UTC as if there was no DST".

But this would de-facto establish its own time zone because it would map 08:00 
"UTC" to both 09:00 and 10:00 in Europe/Berlin, depending on whether DST is in 
effect or not, although 10:00 in Europe/Berlin is 08:00 UTC during DST, while 
in the winter it is 09:00 UTC.

So we then really store in a time zone which you might call UTCWND ("UTC With 
No DST") and store that using RFC3339. This would however mean that we're not 
actually RFC3339 compliant, as RFC3339 specifies UTC and not UTCWND.

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/20110321/638f81cb/attachment.sig>