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

[Hendrik Helwich]

Hi Georg,

Am Montag, 20. Dezember 2010 12:40:09 schrieb 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.

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.

> > 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.

I think not but maybe again an example:
If i want an event happen in 9 o clock in germany the time will be stored as 8 
o clock UTC after KEP 2. The Kolab client application would read from the 
Olson Database that the standard offset is +1 in germany and would know that 
the intended local time is 9 o clock. 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 :-) but it is technically possible 
and maybe there is a real world example which makes more sense).
So the german timezone would be the same like before (except the names of the 
two offset regions) and nothing should change. But the standard time (now in 
the summer) has the offset of +2 instead of +1 before.
A Kolab client would now see the stored time of 8 o clock and will see it as 
10 o clock local time because of the changed offset for the standard time.
So this is a technically possible database change that causes a wrong shown 
local time.

> > 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".

I meant to store a local time in the UTC formatting of RFC3339. So if you have 
a local time of 9 o clock to store it as 9 o clock but in UTC notation.
This is similar like the proposed procedure which leaves away DST but now all 
offset regions are discarded. It is a UTC time which is also wrong, but you 
don't need to add any offsets to it to get the local time. 
But as i wrote before IMO it would be better to write it in a different syntax 
to be able to differ between local and UTC times.

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

The proposed stored datetime is neither a UTC time nor a local time but a 
mixture of both.

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

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.

> 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.

But (b) is the only option from the three which will result in the correct UTC 
time. IMO a time format which is intended to store only UTC datetimes should 
not be used to store (partly) local times.

> 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.

With (a) you have to do
UTC-local-mix -> local
first. If you need the UTC times of a recurring event you need to calculate 
local -> UTC for every occurance.

With (b) the first calculation would not be needed and is the winner. Also you 
do not have to create your own Kolab UTC/local mix time.

> > 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.

IMO this is the best choice because it stores the intended local time, has the 
best readability, has the least calculation complexity and is therefore least 
error prone.
Why should RFC3339 be used for local times if it is not designed for it? This 
makes no sense in my opinion.

> > 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.

This would allow kolab to store local times e.g. like this:
2009-06-30T18:30:00+02:00

So that is a improvement IMO. But you need to store the unnecessary offset to 
UTC. if you leave it away you would have exactly the format that i proposed.
I see no problem in parsing this. You have system libraries for that e.g in C. 
This is on line in code and less error-prone than to use a library for that.
Anyway local times should be stored somehow as local times in the kolab format 
IMO.

Bet regards,
Hendrik

> Best regards,
> Georg