[CalendarServer-changes] [3556] CalendarServer/trunk/lib-patches/vobject/vobject.icalendar.patch
source_changes at macosforge.org
source_changes at macosforge.org
Fri Dec 19 11:06:20 PST 2008
Revision: 3556
http://trac.macosforge.org/projects/calendarserver/changeset/3556
Author: cdaboo at apple.com
Date: 2008-12-19 11:06:19 -0800 (Fri, 19 Dec 2008)
Log Message:
-----------
Handle case of floating time DTSTART and UTC UNTIL.
Modified Paths:
--------------
CalendarServer/trunk/lib-patches/vobject/vobject.icalendar.patch
Modified: CalendarServer/trunk/lib-patches/vobject/vobject.icalendar.patch
===================================================================
--- CalendarServer/trunk/lib-patches/vobject/vobject.icalendar.patch 2008-12-19 17:12:45 UTC (rev 3555)
+++ CalendarServer/trunk/lib-patches/vobject/vobject.icalendar.patch 2008-12-19 19:06:19 UTC (rev 3556)
@@ -2,7 +2,26 @@
===================================================================
--- vobject/icalendar.py (revision 212)
+++ vobject/icalendar.py (working copy)
-@@ -1661,9 +1661,10 @@
+@@ -426,6 +426,18 @@
+
+ if dtstart.tzinfo is not None:
+ until = until.astimezone(dtstart.tzinfo)
++
++ # RFC2445 actually states that UNTIL must be a UTC value. Whilst the
++ # changes above work OK, one problem case is if DTSTART is floating but
++ # UNTIL is properly specified as UTC (or with a TZID). In that case dateutil
++ # will fail datetime comparisons. There is no easy solution to this as
++ # there is no obvious timezone (at this point) to do proper floating time
++ # offset compisons. The best we can do is treat the UNTIL value as floating.
++ # This could mean incorrect determination of the last instance. The better
++ # solution here is to encourage clients to use COUNT rather than UNTIL
++ # when DTSTART is floating.
++ if dtstart.tzinfo is None:
++ until = until.replace(tzinfo=None)
+
+ rule._until = until
+
+@@ -1661,9 +1673,10 @@
else:
current.append(char)
else:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20081219/1fe11760/attachment.html>
More information about the calendarserver-changes
mailing list