Why and when storing local time? (Re: Basic rationale of the KEP #2 design)
Florian v. Samson
florian.samson at bsi.bund.de
Fri Mar 18 17:39:48 CET 2011
Am Dienstag, 15. März 2011 um 16:48:40 schrieb Bernhard Reiter:
> Am Dienstag, 15. März 2011 14:05:26 schrieb Jeroen van Meeuwen (Kolab
> > 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.
IMHU he proposed UTC + TZ-ID.
> 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.
I agree to both requirements, which can be fulfilled by UTC + TZ-ID *and*
LocalTime + TZ-ID as well.
> 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
Sorry this is not conclusive for me, these are rather generic statements.
But UTC + TZ-ID can fulfil your "conclusion" above and LocalTime + TZ-ID
implicitly fulfils it.
For UTC + TZ-ID to fulfil the requirements i) and ii), in-format TZ-data has
to be used and the client updating this TZ-data in the Kolab-object is
responsible to adjust (i.e. either alter or split) the event according to a
set of rules we would have to specify.
> > > 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
Ugh, I was reluctant to propose above due to its complexity, but proposing a
wild mix of UTC and LocalTime date-times sounds pretty complex and
error-prone as well.
More information about the format