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

Florian v. Samson florian.samson at bsi.bund.de
Tue Mar 29 14:28:05 CEST 2011


Georg,

Am Freitag, 25. März 2011 um 16:46:20 schrieb Georg C. F. Greve:
> On Tuesday 22 March 2011 11.48:27 Florian v. Samson wrote:
> > I clearly answered that: Any source, which is providing sufficient
> > data, e.g. the web-service you named more than once.
>
> Ok. So it seems there was a misunderstanding and we do agree that it
> makes sense to use TZ data sources such as the system wide databases or
> the web service which is under RFC-drafting.

Again, IMO it makes sense to allow a Kolab-client to use *any* source of 
TZ-data in order to (depending on the primary data source defined in a 
final Kolab-format v2) ...
a. put in an in-format TZ-data field.
or
b. consume it directly.

> > 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.
>
> Ah, on the reasoning we agree.

The I would appreciate very much, if the reasoning does get well documented 
in the KEP.  As I described in more detail before, this is not the case 
today, IMO.

> > > 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 how do you know which is the UTC for 13:00 in Europe/Berlin on
> 30.3.2015?

By taking a closer look at the TZ-data, which accompanies the 
TZ-ID "Europe/Berlin": add the offset, which is valid for that date (likely 
to be "-02:00" for the 30 March 2015, see below) to the local time.
This results in 11:00 UTC, right?

> My understanding is that you would use the same rules you have today as
> those are the best information you have, and thus calculate UTC based on
> those rules. But this is merely an assumption. You do not know whether
> those rules are going to change between now and 2015.

This example is very fuzzy, please be concise.  
I see at least two different cases addressed here:
1. The DST switching dates for this specific TZ are not defined yet.
2. The DST rules for this specific TZ are redefined (i.e. they are altered),
   but they have been defined (although differently) before.
Which one did you intend to address?

> So in order to correctly interpret UTC + TZID, you also need the
> assumption about DST rules that the initial client made when writing the
> event, 

Thanks a lot for finally defining the awkwardly curtailed "DST assumption" 
as "the assumption about DST rules that the initial client made when 
writing the event": IOW this simply is "the TZ-data which was used when the 
Kolab-object was created".
So the "DST assumption" (whose meaning I never really comprehended) simply 
means "the TZ-data used", right?  Or is there some aspect I missed?

And thanks for pointing out this big advantage of in-format TZ-data:
For case 1 above (TZ-data not yet preassigned by legal authorities) a single 
source of TZ-data in the Kolab-object would prevent that every client my do 
its own (potentially deviating) extrapolation of the (definitely deviating) 
local sources of TZ-data (e.g. a local installation of the Olson database).

> which ultimately boils down to a pre-processing step whether the 
> stored UTC was correctly calculated and can be relied upon, or needs to
> be adjusted.

No, not at all!  By definition of this process, the stored UTC *is* 
correctly calculated against the TZ-data used and *must* be relied upon 
(what else would you rely on?). 
Only if a client changes in-format TZ-data, this specific client must adjust 
UTC-timestamps accordingly, so the the resulting local time stays the same.


Cheers
	Florian




More information about the format mailing list