Tickets :: Comment on [#13866] CalDAV PUT parses multiple VTIMEZONE data incorrectly, even its own ones

Search Results: 95 of 248 [ <<First <Prev Next> Last>> ] [ Return to Search Results ]

* Your Email Address
* Spam protection	Enter the letters below: .__ . .. ..__.. . [ __\|\/\|\| \|\| \|\|__\| [_./\| \|\|__\|\|__\\| \|
Comment	> I stumbled over the exact same problem last month (mid of march 2013). > Today i found some time to track this down. > > Problem is the gmmktime() call in > framework/Icalendar/lib/Horde/Icalendar/Vtimezone.php (lines 154, > 155). > Attached is a patch to fix this. > gmmktime is called with parameter $year which holds the year the > event actually occurs, instead $result['end'] should be used which > holds the year value of the RRULE UNTIL field. > > Some background information: > Hint: Everything is related to timezone Europe/Berlin. It may may > affect other timezones too, but did no tests. > > The problem is only visible every year for events between the 1st of > january and the real date for the switch to summertime (CEST), eg. > 29th march 2015. > The CalDAV client has to do the following, which most clients ("em > Client" in my case) do: > >> GET url > modify event >> PUT url >> GET url > > While handling the PUT request, Horde parses all timezone entries of > the submitted isc file (framework/Icalendar/lib/Horde/Icalendar.php > line 1249). > For all entries without RRULE everything is fine and correctly parsed > and converted to timestamps, but RRULEs are completely wrong. > Here the example: > >> BEGIN:DAYLIGHT >> TZOFFSETFROM:+0100 >> TZOFFSETTO:+0200 >> DTSTART:19170416T020000 >> RRULE:FREQ=YEARLY;BYMONTH=4;BYMONTHDAY=15,16,17,18,19,20,21;BYDAY=1MO;UNTIL >> =19180421T000000Z >> TZNAME:CEST >> END:DAYLIGHT > > This results in the follwoing gmmktime() call: > gmmktime(3, 0, 0, 4, 1, 2015) = 1427857200 = "Wed Apr 1 05:00:00 CEST 2015" > > After further processing the value gets even worse to "Wed Apr 6 > 05:00:00 CEST 2015" but thats not relevant for demonstarting what > happens. > > As the DTSTART is 19170416T020000 (something around -1663448400 as > timestamp)you get an $change_times array like this: > > $change_times[0]['time']=-1663448400 > $change_times[0]['from']=3600 > $change_times[0]['to']=7200 > $change_times[1]['time']=1427857200 > $change_times[1]['from']=3600 > $change_times[1]['to']=7200 > > The array is actually much larger but only those entries are relevant > as all other following entries are wrongly not used, see the > following. > > Now there is the comparison in > framework/Icalendar/lib/Horde/Icalendar.php line 1282: > > if (($t >= $change_times[0]['time']) && > ($t < $change_times[0 + 1]['time'])) { > return $change_times[0]['to']; > > Assume an event on "Thu Mar 26 08:00:00 CET 2015" which gmmktime'ed > by Horde itself "1427356800". > 1427356800 >= -1663448400 && 1427356800 < 1427857200 -> return 7200 > > So you actually get an offest of 7200 instead of 3600 and the entry > is stored one hour off in the database and returned one hour off back > to the client during the next CalDAV GET request and also shown one > hour off in the Horde WebUI. > > You can reproduce this for every year, as long as timezone > "Europe/Berlin" is used and the event is sometimes between 1st of > january and the real day of the switch from CET to CEST in this year. > > I hope this is enough information to illustrate the root of the problem. > > The attached patch is tested to work correctly. > A more complete and probably better solution would be to check the > actual year of the event against the year for every timezone rule and > only handle those rules that could affect the event and save some CPU > cycles not processing rules from decades in the past ever and ever > again, but that's another story. > > Kind regards > Joerg
Attachment
Watch this ticket

Saved Queries