[Cosmo] Time Range Query Problem

Bobby Rullo br at osafoundation.org
Fri Jan 13 16:22:56 PST 2006

Thanks Cyrus. I'm almost with you (I really need to re-read the  
latest CalDAV draft!)

 From what you said, I think this is buggy behavior:

I do the following query to get back all events between 1/3/2006 and  

<?xml version="1.0"?>
<C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
     <D:prop xmlns:D="DAV:">
             <C:expand end="20060109T000000Z" start="20060103T000000Z"/>
         <C:comp-filter name="VCALENDAR">
             <C:comp-filter name="VEVENT">
                 <C:time-range end="20060109T000000Z"  

And I get back, (amongst other things) the following event:
PRODID:-//OSAF//NONSGML Scoooby Server//EN

The two problems I see here are that:

	1) My query should not return any floating events
	2) This event is on January 2nd, which is out of that range


On Jan 12, 2006, at 9:32 AM, Cyrus Daboo wrote:

> Hi Bobby,
> --On January 11, 2006 2:09:54 PM -0500 Bobby Rullo  
> <br at osafoundation.org> wrote:
>> Ok. I think I got you so let me get this straight:
>> If I want to get all the events (floating or otherwise!) for a given
>> timezone I need to either
>> 	1) Pass the timezone in the with the timerange
>>          2) Convert the desired date range into UTC and use these UTC
>> times as the time range
> Not quite - you always use UTC date-times in the time-range  
> element. You need to adjust that as appropriate for the client  
> timezone (i.e. if you want one days worth of events in US/Pacific,  
> that would be start=20060112080000Z, end=20060113080000Z. That will  
> take care of matching any non-floating events on the server. To  
> properly match floating events (which includes date only events)  
> you should also provide the timezone object in the timezone element  
> in the report request. That will allow the server to correctly  
> determine that an all day event for 20060113 is NOT supposed to be  
> returned
>> But in Cosmo, only option 2) will work now, right?
> Right now cosmo does not parse the timezone element in the report  
> but internally it does use a timezone when forming the query - that  
> right now defaults to UTC. What remains to do is hook up the  
> timezone element and the calendar-timezone proeprty
> -- 
> Cyrus Daboo

More information about the Cosmo mailing list