[Tickets #13223] Re: [Icalendar] Import of ics with a timezone that no longer observes DST fails.

[noreply at bugs.horde.org]

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

Ticket URL: http://bugs.horde.org/ticket/13223
------------------------------------------------------------------------------
  Ticket             | 13223
  Updated By         | amessina at messinet.com <amessina at messinet.com>
  Summary            | [Icalendar] Import of ics with a timezone that no
                     | longer observes DST fails.
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Assigned
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             | Jan Schneider, Michael Rubinsky
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2014-05-27 01:51) wrote:

For timezones that, at one point in the past, observed DST but no  
longer do, dates will be imported using the offset from the most  
recent vTimezone component without an UNTIL in the RRULE.

For example, the attached ics from Simon Wilson is in  
Australia/Brisbane timezone, which does not observe DST, but did in  
the past. All of the components with RRULEs have UNTIL dates in the  
past because currently this timezone ONLY observes standard time.

However, the most recent component in the vTImezone that does NOT have  
an UNTIL happens to be a component describing a DST transition (other  
DAYLIGHT components appear after this initial one, but they all  
contained UNTIL). So, when Horde_Icalendar_Vtimezone::parseChild() is  
called in Horde_Icalendar_Vtimezone::_parseTZID() this is the most  
recent component that is included in the $change_times array:

array(6) {
   [0]=>
   array(3) {
     ["time"]=>
     int(-1672567140)
     ["from"]=>
     int(36000)
     ["to"]=>
     int(39600)
   }
   [1]=>
   array(3) {
     ["time"]=>
     int(-1665388800)
     ["from"]=>
     int(39600)
     ["to"]=>
     int(36000)
   }
   [2]=>
   array(3) {
     ["time"]=>
     int(-883641600)
     ["from"]=>
     int(36000)
     ["to"]=>
     int(39600)
   }
   [3]=>
   array(3) {
     ["time"]=>
     int(-876124800)
     ["from"]=>
     int(39600)
     ["to"]=>
     int(36000)
   }
   [4]=>
   array(3) {
     ["time"]=>
     int(-860400000)
     ["from"]=>
     int(36000)
     ["to"]=>
     int(39600)
   }
   [5]=>
   array(3) {
     ["time"]=>
     int(-828345600)
     ["from"]=>
     int(36000)
     ["to"]=>
     int(39600)
   }
}


Therefore, when looking for the correct offset to return, the DST  
offset of 39600 is returned instead of the correct 36000.