How to conclude KEP2 for good

Florian v. Samson florian.samson at bsi.bund.de
Tue Apr 5 10:09:04 CEST 2011


Jeroen,

Am Montag, 4. April 2011 um 20:19:22 schrieb Jeroen van Meeuwen (Kolab 
Systems):
>
> Perhaps consider splitting up the KEP (retiring this one) as per my
> suggestion four months and some weeks ago;
>
> http://kolab.org/pipermail/kolab-devel/2010-November/012504.html
>
> After all, there seem to be two legs in the KEP #2 discussion;
>
> 1) the inclusion of a 'tz' tag or attribute including;
>
>   - what the value for it should be,
>   - which datetime stamps are to include the 'tz' tag/attribute,
>   - which values to use for the 'tz' tag/attribute, and
>   - where to obtain UTC offsets and DST changes from, given any of the
> allowed 'tz' tag/attribute values.
>
> 2) the datetime itself and notation format thereof, including;
>
>   - whether or not to use UTC or local time in the datetime stamp,
>   - what datetime stamp notation format to use (applicable to using local
> time only)
>
> One is not tied in with the other.

Oh, I did believe so as well as couple of months ago, but meanwhile for me 
(and Georg) it became apparent, that choosing UTC in (2a) needs embedding 
TZ-data in (1d).  ["DST assumption" was Georg's term, though it is more 
than that as Bernhard depicted: "The TZ-data/-definition used for the 
calculation of UTC date-times".]
OTOH I have the gut feeling, that date-times expressed in local time 
directly is easier to design (and may work better) with a local source of 
TZ-data.

Still I do agree, that splitting the as you proposed would ease the process, 
but they are connected, and some choices in (1) may preclude or hinder some 
of the available choices in (2) and vice versa.

Cheers
	Florian




More information about the format mailing list