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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13866
------------------------------------------------------------------------------
  Ticket             | 13866
  Updated By         | Joerg.Pulz at frm2.tum.de
  Summary            | CalDAV PUT parses multiple VTIMEZONE data incorrectly,
                     | even its own ones
  Queue              | Synchronization
  Version            | FRAMEWORK_5_2
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Jan Schneider
+New Attachment     | framework_Icalendar_lib_Horde_Icalendar_Vtimezone.php
------------------------------------------------------------------------------


Joerg.Pulz at frm2.tum.de (2015-04-14 20:01) wrote:

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



Joerg.Pulz at frm2.tum.de (2015-04-14 20:01) uploaded:  
framework_Icalendar_lib_Horde_Icalendar_Vtimezone.php

https://bugs.horde.org/h/services/download/?app=whups&actionID=download_file&file=framework_Icalendar_lib_Horde_Icalendar_Vtimezone.php&ticket=13866&fn=%2Fframework_Icalendar_lib_Horde_Icalendar_Vtimezone.php