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

[Georg C. F. Greve]

Hi Hendrik,

Good to hear that you also see the issue.

Let's see whether we can find agreement on how to resolve it.


On Monday 20 December 2010 11.11:33 Hendrik Helwich wrote:
> i think it is not nice to store a wrong UTC time half the year. 

I'm not sure that it's wrong to store correct UTC for a location based on that 
location's standard time. This is its correct time zone, after all, to which 
DST is a temporary and flexible deviation.


> Also technically it is possible that the standard time changes for a time
> zone. This would break the hole concept. I am not sure if this could happen
> in practice but from the format it is possible.

Well, I presume it is theoretically possible that a location would change its 
time zone altogether. But then I don't see this realisticially happening for 
any other reason than some micro-dictatorship going nuts and wanting some 
other time zone than its hated neighbours.

And I dare say that groupware is going to be the least of that countrys 
issues, considering the level of disruption this kind of time zone change 
would cause on all levels. 

But even so, this change in time zone would then also reflect itself in the 
Olson database, which also stores the standard time offset to UTC at any given 
point in time, so the proposed solution *is* robust even against this case.


> So if already a wrong UTC time is stored half the year it could also be
> stored wrong for the hole year by storing directly the local time as UTC.
> This will be less error-prone.

There is no such thing as storing "local time as UTC".

There is UTC, and then there is local time. The two have an ambiguous 
relationship. You'll need to resolve that relationship either way.

Whether you take UTC or local time as your starting point, the complexity of 
the problem and the corresponding calculations always remains the same.

There are really only three options that I consider realistic:

 (a) store UTC from standard time

 (b) store UTC from local time + flag "fromDST"

 (c) store local time

Of these, (a) and (c) have the same level of complexity, whereas (b) adds one 
layer of complexity, and thus should be discarded immediately.

In comparison between (a) and (c) I think (a) is clearly the winner, because 
it ensures that events are tied closely to UTC, and thus timestamps can be 
compared without conversion. Otherwise you would always have to convert first 
and then compare, which would affect for instance free/busy list creation.


> But IMO it would be much nicer to store local times in a different format
> than UTC e.g. by dismissing the trailing 'Z' character. 

This creates a fourth option

 (d) create new, standards-incompatible time format to store local time

which has the same issues as (c), and creates additional error potential 
because it looks a lot like RFC3339, but it isn't. So clients are likely to 
interpret this as UTC, when it is not. So of all the possible solutions, this 
would be my least favorite and the most error prone.


> The syntax of the datetime should match the needs of the Kolab XML. If the
> RFC3339 syntax does not match to that need it should be adapted in that case
> IMO. RFC3339 seems not to be intended to store local times with it.

RFC3339 is a subset of ISO8601 for UTC based time storage.

If we wanted to go for local time, which I don't think we should do, we should 
then use the standard for this purpose, which would be ISO 8601.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

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: <http://lists.kolab.org/pipermail/format/attachments/20101220/71bff1e8/attachment.sig>