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