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

[Christian Mollekopf]

On Monday 16 July 2012 11.49:44 Jeroen van Meeuwen wrote:
> On Saturday, July 14, 2012 03:44:25 PM Christian Mollekopf wrote:
> > On Friday 13 July 2012 13.17:11 Jeroen van Meeuwen wrote:
> > > Hi there,
> > > 
> > > For resource management, I'm starting to implement a certain level of
> > > timezone support - actually quite important.
> > 
> > Something for libkolab, maybe?
> > 
> > > Is it fair to assume that if no specific timezone is specified, any
> > > datetime is UTC?
> > 
> > Depends on the usecase.
> > In cDateTime UTC is indicated by a boolean, and in a string UTC is usually
> > indicated by a "Z" appended
> > (http://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Date-Time).
> > 
> > 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.

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?

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/34710444/attachment.sig>