libkolabxml: When setting a start/end/etc. ...

Christian Mollekopf mollekopf at kolabsys.com
Mon Jul 16 14:43:38 CEST 2012


On Monday 16 July 2012 12.51:53 Jeroen van Meeuwen wrote:
> On Monday, July 16, 2012 01:14:11 PM Christian Mollekopf wrote:
> > On Monday 16 July 2012 11.49:44 Jeroen van Meeuwen wrote:
> > > On Saturday, July 14, 2012 03:44:25 PM Christian Mollekopf wrote:
> > > > Without any timezone identifier, it should be treated as
> > > > floating-time.
> > > 
> > > Right - how does one treat a floating-time in scheduling (the Python
> > > equivalent is a naive datetime) - create a 48 hour margin of error?
> > 
> > Not sure if floating-time is of any use when it comes to scheduling, and
> > as
> > resources also don't travel through timezones I'd do all the scheduling in
> > UTC.
> 
> Some resources do travel (cars, trucks, planes, ships, and whatever one
> takes with them).
> 

Ok, true.

> > I don't know the exact usecase, but assuming it is about a person making a
> > reservation, you could store reservations with timezone or utc, but
> > floating- time shouldn't be allowed I think. Otherwise you get constantly
> > changing reservations, depending on where the person that made the
> > reservation is, which is a bit difficult to implement ;-)
> > 
> > When doing the f/b calculations I will then convert everything to UTC
> > anyways.
> > 
> > Or where do you have the floating-time from?
> 
> Any arbitrary iTip may have a DTSTART without timezone details and without
> the 'Z'.
> 

According to iTip RFC 5546 as well as the iCalendar vFreebusy component all 
dtStart/dtEnd MUST be in UTC. The only exception is the vTimezone component in 
the iTip RFC, where local time MUST be used. Or am I missing something?

> One (stupid) example is an all-day event (which isn't a datetime, but a
> date, but still the 1st of January isn't the 1st of January at the same
> time everywhere in the world).
> 

Indeed. The current f/b code interprets any date-only value as UTC 00:00 
-23:59:59, which is not really correct and should be interpreted in the local 
timezone I think. So we probably should make the "local" timezone on the 
server configurable (as georg pointed out). Possibly something for libkolab?

Cheers,
Christian

> Kind regards,
> 
> Jeroen van Meeuwen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20120716/a8970f44/attachment.sig>


More information about the format mailing list