Basic rationale of the KEP #2 design

Georg C. F. Greve greve at
Tue Mar 15 10:00:03 CET 2011

Dear Jeroen,

While I think your points on RFC3339 are valid, as stated before, Hendrik has 
a point when it comes to local time storage.

On Monday 14 March 2011 23.04:51 Jeroen van Meeuwen (Kolab Systems) wrote:
> You stated there is no way to restore the originally intended local time
> when  UTC datetimes are used, but it seems the last-modification datetime
> has been overlooked. 

No, because the last-modification contains only the last modification date.

It is therefore not a source of information for whether the client that wrote 
the initial target time for the appointment assumed that that particular 
future time would be within DST or not.

The last-modification date only speaks about the current time, and may not even 
have been written by the client initially writing the appointment, as another 
client may have modified the event subsequently (e.g. the participants, or 
exceptions to recurrence).

> You stated clients cannot foretell the future, but back in those days of
> the  discussion, where the 'tz' attribute was only supposed to indicate
> the authoritative timezone that should be used, a timestamp for 18:00 UTC
> with a 'tz' attribute set to Europe/Berlin had been consistently saying
> the same thing at the data storage level 

It may look the same at a storage level, but may represent both

	19:00 in Europe/Berlin
	20:00 in Europe/Berlin

in a user's intention. Without knowing whether the client that wrote this 
appoinment predicted DST to be in effect for the first occurence of this event, 
that is impossible to determine.

> A very simple fix would have been to specify clients must
> write out the datetime as if DST was never invented, and only use their
> baseline offset; two situations for writing the data out exist:

I also thought at some point this might resolve the situation, and I believe 
there even was a version of the KEP that attempted it.

The problem is that it irrevocably falsifies the entries.

10:00 in Berlin in the summer is 08:00 UTC, not 09:00 UTC, as would be written 
out if following the logic proposed above. Comparisons of entries based on UTC 
would therefore become impossible, because one would necessarily have to first 
translate into local time, and back into "real UTC" to know how they actually 
relate to each other.

Such storage, while also being RFC3339 incompliant because it does not 
actually map to UTC directly, does not seem an improvement over storing local 
time directly.

For some other entries, e.g. last-modified, such a falsification of the datetime 
field would likely throw off a substantial number of clients which are unlikely 
to care for the time zone of this field, and just want to use it to sort 
through entries by order of last modification, for instance.

Best regards,

Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at
t: +41 78 904 43 33

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the format mailing list