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

Jeroen van Meeuwen vanmeeuwen at
Mon Jul 16 13:51:53 CEST 2012

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

> 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 

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

Kind regards,

Jeroen van Meeuwen

Systems Architect, Kolab Systems AG

e: vanmeeuwen at
m: +44 74 2516 3817

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>
-------------- 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: <>

More information about the format mailing list