Rationale of the KEP2 design: central in-format TZ-data vs. individual local TZ-databases and more (Part 2)
Georg C. F. Greve
greve at kolabsys.com
Mon Mar 21 13:21:07 CET 2011
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
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
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.
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