Why and when storing local time? (Re: Basic rationale of the KEP #2 design)

[Bernhard Reiter]

Am Dienstag, 15. März 2011 14:05:26 schrieb Jeroen van Meeuwen (Kolab 
Systems):
> The argument on whether or not the ability to foretell the future is a
> client capability is completely moot with a UTC timestamp, as long as the
> operations to be executed against it are specified; write out something UTC
> only negating the baseline UTC offset, now everyone knows what they are
> reading.
>
> You store something that never changes, you interpret it according to the
> specification of the format, and only then present it to the user.

I am not entirely sure what you are proposing. So let me use the opportuniy to 
explain why I believe that we should store the local time plus tz id
of datetimes in the future, in particular  
for start and stop datetimes of events and tasks:

i) The transformation of UTC <---> Local Time of tz=L is not yet fully 
determined for the future. For the past it is fixed as the definition of L
is done. For the future it could change.

ii) I do assume that most of the time a user will think about an event
in Local Time tz=L when she creates it. And whatever happens to the
definition of L in the future, the event should stay there.

Conclusions:
iii) As we do not know precisely what will happen, the best thing we can
do is to save the event as close as to what the user expects. So if everything 
works out fine, we represent the user conception of the event best.

> > 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.
>
> Sorting UTC timestamps is a lot easier then sorting local times with
> offsets, FWIW, unless of course you first translate the local times
> (ignoring the offsets as per specification), using the 'tz' attribute...
> back to UTC.
>
> I would further like to emphasize, and strongly recommend, that the 'tz'
> attribute is introduced only as an attributes to those datettime tags that
> have a use for it; recurring events.

iv) I agree that using the Local Time tz=L variant should only be
recommended for datetimes in the future, where the transformation really 
matters.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3696 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/format/attachments/20110315/f6c74b37/attachment.p7s>