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