KEP2: Modification of datetime type, introduction of 'tz' sub-tag

Georg C. F. Greve greve at
Mon Dec 20 19:19:12 CET 2010

Hi Hendrik,

On Monday 20 December 2010 15.17:59 Hendrik Helwich wrote:
> as i understand time zones, the DST is a part of it.
> So e.g. if you are in germany (where DST is used) and you want a event
> start in the summer at 9 o clock it would have the start time of 7 o clock
> in UTC (DST offset +2). With KEP 2 it would be stored as 8 o clock UTC
> time because the standard offset would be used instead of the currently
> active DST offset. So this would be wrong because the event would happen
> at 7 o clock UTC time and not at 8 o clock UTC time.

You're right of course, which is why the calculation metric to arrive at the 
correct time given in KEP 2 resolves this issue again. But the true point 
you've made, which I only realized later, is that it screws the datetime 

> Everything is fine till now. Somebody now decides to to switch the names of
> DST and standard time in germany (I know this is not very realistic :-) 

In the array of realistic scenarios, this one is somewhere alongside "a giant 
meteor is going to wipe out Germany, speeding up continental drift to displace 
Rome, which now has a new time zone", I dare say. ;)

> I meant to store a local time in the UTC formatting of RFC3339.

Yes. I understood that.

But that format is not UTC formatting, it is RFC3339 formatting of UTC, so 
what you're proposing is to create a new, incompatible and easily confused 
format that looks like RFC3339, but isn't, and gives local times, but many 
parsers may mistakenly read it as UTC, because that is what it looks like.

So I think that's a recipe for desaster.

> This is not true i think. If you want the event to happen in a local time
> (which is probably the default usecase) you only have to convert it back if
> the time is stored in UTC. If it is stored directly in local time you need
> no calculation and have therefore less complexity and a better
> readability.

Actually I think there is a case for storing local time, but this is not it.

> Why should RFC3339 be used for local times if it is not designed for it?
> This makes no sense in my opinion.

I agree. Which is why I didn't agree with your proposal to do so. ;)

The whole thing is really like trying to fit a curve to a straight line, when 
you fix one point, the other half now stands off... let me try to approach this 
from a new angle. Maybe it'll help us clear our minds and get others in on 
resolving this, as well.

I'll start this into a fresh thread...

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