Why and when storing local time?

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Tue Apr 5 16:24:23 CEST 2011


Florian v. Samson wrote:
> Jeroen,
> 
> Am Dienstag, 5. April 2011 um 15:28:23 schrieb Jeroen van Meeuwen (Kolab
> 
> Systems):
> > Florian v. Samson wrote:
> > > Am Dienstag, 5. April 2011 um 12:35:42 schrieb Jeroen van Meeuwen
> > > (Kolab Systems):
> > > 
> > > This is still at most two TZs (and that was the point I intended to get
> > > across).
> > 
> > I'm regularly on flights that invoke presence on the ground in 4-5
> > timezones.
> 
> Well, each flight has a single start- and end-date.
> 
> > CWL -> AMS -> MSP -> PHX and back, for example, was a trip as recent as
> > late last January / early last February.
> 
> I strongly believe we should not expand an event to have more than just a
> single start- and end-date, which may recur regularly.  Metadata
> (creation-time, modification-time, etc.) is in a different realm (but items
> existing only once in a Kolab-object as well).
> Multiple, arbitrary time-ranges must be modelled with independent events,
> IMO, and I think that is more or less the "natural" way of modelling this.
> 

Agreed, either the complete trip or every separate stage during such trip are 
events with one start and one end, and that's how it should be.

I was merely indicating a single event can be perceived to have multiple sub-
events - whether rightfully so or not - marking someone as unavailable during 
travel versus that person pushing out their itinerary to their Calendar... two 
different yet purposeful things.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110405/a2636601/attachment.html>


More information about the format mailing list