Changes have been made in Git (master):

commit 6fc938acefb19b9acc6225da1aa8fd8a641c60b3
Author: Jan Schneider <jan@horde.org>
Date:   Mon Jun 2 11:47:09 2014 +0200

     Sort timezone rule definitions by end date not start date (Bug #13223).

  framework/Icalendar/lib/Horde/Icalendar.php        |   11 ++-
  .../Icalendar/lib/Horde/Icalendar/Vtimezone.php    |   18 ++--
  framework/Icalendar/package.xml                    |   12 ++-
  .../Icalendar/fixtures/vTimezone/Brisbane.ics      |  103 
++++++++++++++++++++
  .../Icalendar/fixtures/vTimezone/Brisbane.txt      |    2 +
  5 files changed, 131 insertions(+), 15 deletions(-)

http://github.com/horde/horde/commit/6fc938acefb19b9acc6225da1aa8fd8a641c60b3

...and the attachment.

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.