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

[Florian v. Samson]

Georg,

Am Montag, 21. März 2011 um 13:21:07 schrieb Georg C. F. Greve:
> 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.

I did by listing a couple of properties you may intended to address with the 
misleading and incorrect distinction between "static" and "dynamic".

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

No, I proposed nothing to which would be accurately described by "static and 
dynamic through a data base", so I think there is something you missed.
I still do not comprehend what you mean with "static and dynamic through a 
data base", asked you to name the wanted properties and suggested some.  I 
am still interested to understand what you mean!

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

Georg, the approach to misinterpret or deny what has been clearly written by 
omitting and ignoring the significant statements is not going to get us 
anywhere: I explicitly did not propose immutable TZ-data and also not that 
the TZ-data is exactly the same for every year.

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

Georg, when you write "updates of that static data", do you consider that 
data still to be called "static"?  IMU (and I think that is common sense) 
something which is alterable is rather dynamic, hence that is "dynamic 
TZ-data".

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

Sorry, I did, twice at least.

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

I clearly answered that: Any source, which is providing sufficient data, 
e.g. the web-service you named more than once.

> Also, the question would be: How would they be propagated in a safe and
> solid way, 

Kolab-Objects are not propagated, AFAIK (i.e. outside of a Kolab 
server-cluster consisting of a master and one or multiple slave servers).

> as we have no way to update them for cases where invitations 
> have been sent and accepted, 

This is a generic issue and there already is an generic solution in place: 
an invitation can be updated by the organiser.
Besides that, it is trivial to state that in "cases where invitations  
have been sent and accepted" are decoupled (= cut off) from changes of the 
Kolab-object: this is always true.

> for instance, or where clients do not have write access, 

They sure cannot update (logically), but I cannot see any reasons, why they 
should hinder the Kolab-object from being updated or read any updated 
Kolab-objects.

> or how do you prevent editing wars between clients who both 
> "know better"?

I did answer that: by the help of a time-stamp. 

> In either case: If you store ONLY static data, how do the clients know
> which time zone to update the entires for? 

By looking at the TZ-ID in that Kolab-object!?!

> And if you store both TZ-ID 
> and static, which of them is authoritative, and how do you enforce that?

I still do not understand what "storing static" is supposed to mean 
precisely, as I am still not aware of any explanation.
I only know what "static" means in common English, which as an adjective is 
basically "fixed" and may be dissected further to "immutable" and "always 
at the same place in the same state" and more.  The noun "static" 
means "electrostatic charge" or "electrostatic fluctuations" and I lack the 
slightest clue how to store that in a Kolab-object.  Please explain your 
use of "static", this time.

But as explained before the TZ-data must specify the timezone the TZ-ID 
identifies.  Anything else does not make any sense, IMHO.

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

Contradictions can only arise if there is redundant data, otherwise there is 
nothing something can contradict to.
But it is actually wrong to state that contradictions will automatically 
arise, when there is redundant data: your take on iCal can be read that 
way.  One can always update all redundant pieces of data in one go, and 
there never will be any inconsistency.

Still, I did not propose to store redundant data in a Kolab-object.

And, BTW, I was surprised to see how well iCal developed over the past 7 
years: I ask myself a couple of times throughout this lengthy discussion on 
this list, if a completely separate Kolab-format is really still necessary, 
when heading to break backward-compatibility.  I believe that many of the 
issues which showed up with Kolab1 would be avoidable with iCal today.

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

Now this comes closer to what I did propose, only that I modelled the 
in-format TZ-data to be the mandatory source of TZ-data for all 
Kolab-format parsers, and if any client with write access has newer TZ-data 
at hand it should update it in the Kolab-object, when he touches it anyway.

Sad though, that you are back at talking about "clients" not 
about "Kolab-format parsers" anymore.

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

No, as a Kolab-format parser does not have to display anything.

> So the questions here are:
>
>  - What kind of client would not necessarily have a TZ database on board?

Kolab-format parsers do not have to, as long such a "necessity" is not 
introduced by KEP2.  So the question to you as the principal author of KEP2 
is, "Can you guarantee that all Kolab-format parsers now and in the future 
can easily access a local database with TZ-data?"
But we have been here before, you keep asking the same questions and I am 
providing the same answers.

> > How can one possibly take something into account, which one cannot
> > possibly be aware of?
>
> 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.

AFAIR I did not accuse you of falsifying and lying about other peoples 
statements.  If I did it sure would be "inacceptable and inadequate to a 
professional conversation", hence I do ask you for a precise quote.  

AFAIR I simply stated there is zero transparency when you write e.g. (no 
real quotes, just phrases) "this has been discussed and it does not work 
that way" or "I interviewed 10 people and they all agreed".  You *could* 
state anything you like, even though I would not expect you to.  The issue 
is that explanations, background information etc. are missing, in short: 
transparency on the technical and procedural level (I explained that point 
already in depth).

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

You seem to be quite sensible when reading, but not when writing, e.g. (not 
literally) "Joon's opinion does not count as he lacks 
understanding", "Florian's opinion does not count as he does not program a 
client".  If anybody would have stated "Georg's opinion does not count as 
he is has less than 3 years experience in the Kolab environment", would 
that have been appropriate in your point of view? (BTW, I am glad that 
nobody did.)
So if you intend to get some tension out of this conversation, feel free to 
start; your paragraph above was rather the opposite, though.

> Forthermore, as explained before your suggestion to forbid or ignore all
> personal discussions between people about topics that are being discussed
> on this list 

I did not suggest anything such; I also clearly stated that in the mail you 
are replying to, here.
I merely tried to suggest that the *reasoning* in this discussions must be 
publicly documented, not just the results.  This is exactly what PEP / KEP 
demands, but I cannot find much of the technical reasoning which is being 
discussed here in KEP2.

And in order to get a picture of the opinions and their origins, it is 
important to know who has which opinion, not just "we met and 10 people 
agreed" or "I telephoned with many people and they all agreed".  
Over the course of this discussion (and because I asked explicitly) 
those "people" have been named, and a few of them (basically Till only) 
have stated their opinion on this list.  So this point is mostly finished.

As you have strong opinions in this matter it is also a bit problematic that 
it is you claiming to transporting many opinions, doing the evaluation of 
opinions and majorities, stating your own opinion, and developing the KEP2.
Still I appreciate that you are carrying out this task, as this longstanding 
issue with the Kolab-format has to be solved sooner or later.

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

There is no "DST assumption": UTC has no DST and the TZ-data implicitly 
includes DST, as it defines the delta between UTC and the local time (which 
includes DST).

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

UTC == "UTCWND".


Regards
	Florian