KEP2: Modification of datetime type, introduction of 'tz' sub-tag
Georg C. F. Greve
greve at kolabsys.com
Mon Dec 20 19:19:12 CET 2010
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
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...
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format