No, it's a package on its own. A versions with the fix has just been released.

Horde_Timezone is part of the horde pear package, right?
If yes, is this issue fixed in horde 5.1.6

Changes have been made in Git (master):

commit 4420e8faaa699d3647d607d091ec74d5f7f58630
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Thu Mar 6 08:25:55 2014 -0500

     Fix variable name.

     Properly fix Bug: 12773

  framework/Timezone/lib/Horde/Timezone.php |    4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

http://git.horde.org/horde-git/-/commit/4420e8faaa699d3647d607d091ec74d5f7f58630

Issue is in Horde_Timezone.

Changes have been made in Git (master):

commit a6b2da1e240066b16ea97dc5e1151cd73fd91169
Author: Michael J Rubinsky <mrubinsk@horde.org>
Date:   Wed Mar 5 21:05:59 2014 -0500

     Fix using a local copy of the tz database.

     Horde_Vfs_File() requires a vfsroot to be set, just read the file
     in directly. Fixes Bug: 12773

  framework/Timezone/lib/Horde/Timezone.php |   23 +++++++++++++++--------
  1 files changed, 15 insertions(+), 8 deletions(-)

http://git.horde.org/horde-git/-/commit/a6b2da1e240066b16ea97dc5e1151cd73fd91169

Fixed locally, will push shortly.

No, not exactly. The Timezone library can't rely on any core specific 
knowledge. I think the correct fix for this issue is to not use 
Horde_Vfs to load the file since it isn't necessarily located within a 
specific virtual filesystem root. We should perhaps just use a file 
pointer directly.

So I have a workaround... but not quite a fix yet.

I started knowing that something is wonky with sending UTC in DTSTART 
and DTEND. Google wasn't doing that in their iCal. Also Google was 
sending a VTIMEZONE section. Investigating the RFC for iCal formats.It 
says:

-----
The "VTIMEZONE" calendar component MUST be present if the iCalendar 
object contains an RRULE that generates dates on both sides of a time 
zone shift (e.g. both in Standard Time and Daylight Saving Time) 
unless the iCalendar object intends to convey a floating time (See the 
section "4.1.10.11 Time" for proper interpretation of floating time). 
It can be present if the iCalendar object does not contain such a 
RRULE. In addition, if a RRULE is present, there MUST be valid time 
zone information for all recurrence instances.
-----

So I added a VTIMEZONE section to my file I posted earlier, horde's 
output.ics. That didn't work. I took that back out, and then just 
changed the dates in DTSTART and DTEND to include a TZID definition 
like in google's ics file. Upon importing this ICS file, it worked 
properly! Clearly the answer is to be using "floating times" as the 
RFC suggests, i.e. not UTC which changes relative to timezones with 
observe DST.

Of course, I'm sure Horde wasn't violating RFC on purpose. So I 
started looking in the Horde code where DTSTART and DTEND are parsed. 
I found this of interest in kronolith/lib/Event.php:

         // For certain recur types, we must output in the event's timezone
         // so that the BYDAY values do not get out of sync with the UTC
         // date-time. See Bug: 11339
         if ($this->recurs()) {
             switch ($this->recurrence->getRecurType()) {
             case Horde_Date_Recurrence::RECUR_WEEKLY:
             case Horde_Date_Recurrence::RECUR_YEARLY_WEEKDAY:
             case Horde_Date_Recurrence::RECUR_MONTHLY_WEEKDAY:
                 if (!$this->timezone) {
                     $this->timezone = date_default_timezone_get();
                 }
             }
         }

Clearly Horde is trying to set a timezone to stay in RFC compliance 
for recurring events. But the TZID parameter was not being sent in the 
DTSTART and DTEND parameters in the ICS download. Skip down to:

             if ($this->timezone) {
                 try {
                     $tz = $GLOBALS['injector']->getInstance('Horde_Timezone');
                     $vEvents[] = $tz->getZone($this->timezone)->toVtimezone();
                     $params['TZID'] = $this->timezone;
                 } catch (Horde_Exception $e) {
                 }
             }

where execution was actually ending in an exception. The line that was 
failing was:

                     $vEvents[] = $tz->getZone($this->timezone)->toVtimezone();

which I just found by inserting some syslog lines here and there until 
I narrowed down the failure. So then inside toVtimezone() I added some 
more debug, but it was never being executed. So I looked in 
pear/php/Horde/Timezone.php to see what was failing. It was the 
function getZone being called above before passing to toVtimezone():

     public function getZone($zone)
     {
         if (!$this->_zones) {
             $this->_extractAndParse();
         }
         $alias = isset($this->_links[$zone]) ? $this->_links[$zone] : $zone;
         if (!isset($this->_zones[$alias])) {
             throw new Horde_Timezone_Exception(sprintf('Timezone %s 
not found', $zone));
         }
         $this->_zones[$alias]->setTzid($alias);
         return $this->_zones[$alias];
     }

I found that

             $this->_extractAndParse();

was the line failing. Looking there, I found what was failing:

     protected function _extractAndParse()
     {
     ....

     if (!$this->_tmpfile) {
         $this->_download();
     }

It was the _download() call failing. Well, turns out _download is 
trying to pull from $conf['timezone']['location'] which is defined in 
kronolith/config/conf.php as ftp://ftp.iana.org/tz/tzdata-latest.tar.gz'

So I found that if you've got SELinux enforcing (which you should), 
you'll need to make sure you enable httpd_can_network_connect so that 
kronolith can download this data from the iana ftp server. You'll also 
need to open iptables/firewall/network access to ftp.iana.org if you 
lock that down. Once I did this, Horde was sending ICS properly again, 
every recurring event had their DTSTART and DTEND parameters with a 
TZID specification. Hooray!

However, for those of us more security-minded, I'd like to *not* have 
httpd_can_network_connect enabled. I'd like to be able to load this 
file in outside of CGI. So I downloaded the file manually and set the 
following in kronolith/config/conf.php:

$conf['timezone']['location'] = 'file:///var/www/horde/tzdata-latest.tar.gz';

But now the code in _download in pear/php/Horde/Timezone.php failed around:

         try {
             if ($url['scheme'] == 'ftp') {
                 $vfs = new Horde_Vfs_Ftp(array('hostspec' => $url['host'],
                                                'username' => 'anonymous',
                                                'password' => 'anonymous'));
             } else {
                 $vfs = new Horde_Vfs_File();
             }
             $this->_tmpfile = $vfs->readFile(dirname($url['path']),
                                              basename($url['path']));
         } catch (Horde_Vfs_Exception $e) {
             throw new Horde_Timezone_Exception($e);
         }

At the point:

                 $vfs = new Horde_Vfs_File();

Should this perhaps be:

                 $vfs = new Horde_Vfs_File(array('vfsroot' => 
Horde::getTempDir()));

as a proper construction?

Hi,

I have some more information. I do not see the bug in the kronolith 
webgui itself. I also do not see the bug when I connect my Android to 
ActiveSync. But, I DO see the bug when I download my ICS file and 
import it into any client. The same goes for webdav. So the question 
is what processing is done differently on an ActiveSync connection 
than in a regular ICS file? How is timezone data swapped in ActiveSync?

For reference purposes, I downloaded my personal calendar from google 
in ICS format. Looking at an individual event:

BEGIN:VEVENT
DTSTART;TZID=America/New_York:20140221T140000
DTEND;TZID=America/New_York:20140221T150000
RRULE:FREQ=WEEKLY;BYDAY=FR
EXDATE;TZID=America/New_York:20140314T140000
DTSTAMP:20140305T190333Z
UID:d1jg92liohlcpe4pc6nn3hl4is@google.com
CREATED:20140212T023446Z
DESCRIPTION:
LAST-MODIFIED:20140218T163947Z
LOCATION:
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Weekly One-on-One with Alice
TRANSP:OPAQUE
END:VEVENT

I see a few things in contrast to an individual event as defined by 
Horde's ICS file:

BEGIN:VEVENT
DTSTART:20140220T190000Z
DTEND:20140220T200002Z
DTSTAMP:20140305T152044Z
UID:20140217112844.M7XYoy9TtQiwYOvfqo8h9w5@webmail.MYDOMAIN.COM
CREATED:20140217T162937Z
LAST-MODIFIED:20140304T194922Z
SUMMARY:Bob - Individual Weekly Meeting
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TH
EXDATE;TZID=America/New_York:20140220T190000Z
END:VEVENT

Is it proper for Horde to not put the timezone in the dtstart and 
dtend fields? Right now Horde is saying the event occurs from 19:00 
Zulu to 20:00 Zulu instead of saying 14:00-15:00 America/New_York. 
When Daylight Saving Time hits, Zulu time and America/New_York change 
relative to one-another as there is no DST in UTC.

I also noticed at the beginning of the ICS file that google calendar 
gave, there is a section like this:

BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE

This seems to pretty clearly define DST behavior for the calendar 
software. This entire section is absent in the Horde ICS file.

I am updating this ticket with this information following sending same 
to the horde mailing list for discussion.

And lastly here is the ics output which is displaying incorrectly in 
evolution, lightning, and outlook. I can maybe also get you the caldav 
equivalent of this data if you'd like, both formats are displaying the 
problem.

Fourth file is my calendar entries, as they appear in the horde 
database. Let me know if anything seems funny in this one in 
particular. One entry has a non-null timezone, it still displays the 
off-by-one error however.

Third file is the kronolith conf.php

My second file here is my main horde conf.php.

First some server information, then I will upload each configuration 
file individually as I guess I can only upload one at a time. All 
configuration files and outputs have been sanitized in ALL CAPS for 
obviousness.

I am running horde on a RHEL 6.5 server with PHP 5.3.3, Mysql 5.1.73, 
and httpd 2.2.15. My system timezone is set properly as far as PHP is 
concerned:

[root@webmail ~]# echo "<?php echo(date_default_timezone_get()); ?>  " | php
America/New_York

My first file, attached here, is my system wide php.ini

...and I still cannot reproduce ANY of this.

Some more testing reveals I have the off-by-one-hour behavior also in 
the Horde webview kronolith itself, and in outlook clients subscribed 
via ical. Events afflicted were created using Linux and Mac, both via 
lightning and inside the kronolith webgui itself! This is pretty 
far-reaching.

Hi,

Some proper testing and bug documentation needs to be done here. I am 
experiencing this same bug in our installation. I have exported both 
caldav and ics versions to lightning and evolution on Linux and I see 
the off-by-one-hour behavior. I also see the off-by-one-hour behavior 
in lightning on Mac OSX. The events were created via lightning on both 
Linux and Mac among multiple user accounts. I do not subscribe to 
activesync for any of these clients, so I haven't put the calendar 
into my android, but it is not acceptable to say that one client in 
particular works therefore the whole package works. Google software 
does a lot of stuff behind the scenes. An additional point of interest 
is that once my event that was originally scheduled for 2pm is now at 
3pm, if I attempt to move the item back to 2pm, the server update 
always fails. Upstream, please test without activesync, use a 
Linux/Mac host and either evolution or lightning which are broken for 
myself and  my users. Bottom line, to channel Linus: "the end user 
doesn't care."

I am trying to help out, I am looking through the horde code currently 
to see if we could perhaps make a special exception depending on the 
client software. Right now I am reduced to modifying the database each 
time daylight savings comes about, something like:

select * from kronolith_events where `event_creator_id`='USERNAME' and 
`event_recurtype`!=0 order by event_id desc \G

will show you a list of events that need to be tweaked up an hour or 
back an hour depending on which user you want to "tweak". But this 
isn't a perfect solution, if the user scrolls too far ahead in their 
calendar, the event is still at the wrong time. So it could be a 
problem when you're scheduling for next week (6 days from right now is 
DST in NYC).

TL;DR: PLEASE RECLASSIFY THIS TICKET TO OPEN NEEDING INVESTIGATION!

you have to test via caldav and lightning only, this bug does not 
apear via active sync to i.e my android phone 4.2 !!! This seems the 
best argument that it is a lightning bug, or at minimum a conversation 
bug between horde and lightning via caldav only

just retestet, bug stays, output thunderbird console

upload

CalDAV: send: BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20140206T192425Z
LAST-MODIFIED:20140206T192618Z
DTSTAMP:20140206T192618Z
UID:9a24f216-7f97-46cb-ae01-8bab34abc4a7
SUMMARY:weekly-event-berlin-time-21:00-22:00
RRULE:FREQ=WEEKLY
DTSTART;TZID=Europe/Berlin:20131021T210000
DTEND;TZID=Europe/Berlin:20131021T220000
END:VEVENT
END:VCALENDAR

download

CalDAV: recv:
<d:multistatus><d:response><d:href>/rpc.php/calendars/robert@schetterer.org/calendar:7wLXUUVCZ7LIZM38BLTRuA2/9a24f216-7f97-46cb-ae01-8bab34abc4a7.ics</d:href><d:propstat><d:prop><cal:calendar-data>BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:Kalender von robert@schetterer.org
PRODID:-//The Horde Project//Horde iCalendar Library//EN
BEGIN:VEVENT
DTSTART:20131021T190000Z
DTEND:20131021T200000Z
DTSTAMP:20140206T192619Z
UID:9a24f216-7f97-46cb-ae01-8bab34abc4a7
CREATED:20140206T192618Z
LAST-MODIFIED:20140206T192618Z
SUMMARY:weekly-event-berlin-time-21:00-22:00
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO
END:VEVENT
END:VCALENDAR
</cal:calendar-data><d:getetag>"6dcf5b108cf31acaabdecf45cc6a955c"</d:getetag></d:prop><d:status>HTTP/1.1 200 
OK</d:status></d:propstat></d:response></d:multistatus>

export from horde

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:Kalender von robert@schetterer.org
PRODID:-//The Horde Project//Horde iCalendar Library//EN
BEGIN:VEVENT
DTSTART:20131021T190000Z
DTEND:20131021T200000Z
DTSTAMP:20140206T193157Z
UID:9a24f216-7f97-46cb-ae01-8bab34abc4a7
CREATED:20140206T192618Z
LAST-MODIFIED:20140206T192618Z
SUMMARY:weekly-event-berlin-time-21:00-22:00
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO
END:VEVENT
END:VCALENDAR

show orginal event from lightning ( first event  from choose edit all 
events orginal ics)

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20140206T192618Z
LAST-MODIFIED:20140206T192618Z
DTSTAMP:20140206T192619Z
UID:9a24f216-7f97-46cb-ae01-8bab34abc4a7
SUMMARY:weekly-event-berlin-time-21:00-22:00
STATUS:CONFIRMED
RRULE:FREQ=WEEKLY;BYDAY=MO
DTSTART:20131021T190000Z
DTEND:20131021T200000Z
CLASS:PUBLIC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

show event in lightning with wrong time ( after daylight change, from 
choose edit all events orginal ics )

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20140206T192618Z
LAST-MODIFIED:20140206T192618Z
DTSTAMP:20140206T192619Z
UID:9a24f216-7f97-46cb-ae01-8bab34abc4a7
SUMMARY:weekly-event-berlin-time-21:00-22:00
STATUS:CONFIRMED
RRULE:FREQ=WEEKLY;BYDAY=MO
DTSTART:20131021T190000Z
DTEND:20131021T200000Z
CLASS:PUBLIC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

same but show current event

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VEVENT
CREATED:20140206T192618Z
LAST-MODIFIED:20140206T193940Z
DTSTAMP:20140206T193940Z
UID:9a24f216-7f97-46cb-ae01-8bab34abc4a7
SUMMARY:weekly-event-berlin-time-21:00-22:00
STATUS:CONFIRMED
RRULE:FREQ=WEEKLY;BYDAY=MO
DTSTART:20131021T190000Z
DTEND:20131021T200000Z
CLASS:PUBLIC
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR

I just tried this in Lightning. I created a new recurring event in my 
local timezone, which observes DST. The event was successfully created 
in lightning, synchronized to Horde and synchronized from Horde to all 
of my currently connected activesync clients.

On ALL clients the event appeared to occur at the correct time, 
regardless of how many DST transitions have occurred between the start 
of the series and the instance I was looking at.

Going to mark this not a bug until somebody can provide data to allow 
a developer reproduce this.

perhaps this help ,some errors years ago with pure webdav

https://bugzilla.mozilla.org/show_bug.cgi?id=520843

related fix

http://bugs.horde.org/ticket/7156

Sorry Michael, cant help more, thats beyond my jedi powers
If there is no Problem in Horde, an exact description what to do 
fixing it  should go to the Mozilla Ticket,  i am with you that the 
problem might fixed there and not in Horde.  Direct conversation with 
lightning and horde coders might be the fastest way in fixing this

It's the same code that parses and generates the ics data.

export and import ics file might not the same as upload events via 
caldav from lightning to horde and vice versa, but this is where the 
"bug" happens

Well, first of all, the sample ics files you posted below are not 
complete. The first one is missing the full vTIMEZONE component. 
Second of all, if I import a complete ics file, with the proper 
components, and then export it, I get the correct time values. The 
following is a kronolith export of the event described by your sample 
ics file:

BEGIN:VCALENDAR
VERSION:2.0
X-WR-CALNAME:Yopopipip
PRODID:-//The Horde Project//Horde iCalendar Library//EN
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20131021T140000
DTEND;TZID=Europe/Berlin:20131021T150000
DTSTAMP:20140206T140923Z
UID:6824a851-a5c8-4b1c-aa66-5da72756d071
CREATED:20140206T140716Z
LAST-MODIFIED:20140206T140716Z
SUMMARY:Mo-14-15
DESCRIPTION:Mo-14-15
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19160430T230000
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19161001T010000
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19170416T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYMONTHDAY=15,16,17,18,19,20,21;BYDAY=1MO;UNTIL
  =19180421T00000Z
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19170917T020000
RRULE:FREQ=YEARLY;BYMONTH=9;BYMONTHDAY=15,16,17,18,19,20,21;BYDAY=1MO;UNTIL
  =19180915T00000Z
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19400401T020000
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19421102T020000
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19430329T020000
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19431004T020000
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19440403T020000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1MO;UNTIL=19450401T01000Z
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19441002T020000
TZNAME:CE-T
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
DTSTART:19450916T020000
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0300
DTSTART:19450524T020000
TZNAME:CEMT
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
DTSTART:19450924T030000
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19451118T020000
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19460414T020000
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19461007T020000
TZNAME:CE-T
END:STANDARD
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0100
DTSTART:19471005T020000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU;UNTIL=19491002T01000Z
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19470406T030000
TZNAME:CEST
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
DTSTART:19470511T020000
TZNAME:CEMT
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
DTSTART:19470629T030000
TZNAME:CEST
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
DTSTART:19480418T020000
TZNAME:CEST
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
DTSTART:19490410T020000
TZNAME:CEST
END:DAYLIGHT
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19800406T010000
RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=19800406T00000Z
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19800928T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=9;UNTIL=19950923T23000Z
TZNAME:CE-T
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19810329T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T010000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CE-T
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

Hi Michael , whatever the reason is, it need to be fixed, cause its a 
real showstopper for using Horde with Thunderbird Lightning. There is 
a ticket at Mozilla about it too, so what can be done to get this fixed.

We *absolutely* take into account recurrence series. We explicitly add 
the timezone information to the vCalendar when we are outputting 
recurring series. You can see this in Kronolith_Event::toiCalendar(). 
If the event is being output in UTC, then that means that either the 
event's timezone was explicitly set to UTC or there was no explicit 
timezone set and the default timezone for the user in question is UTC.

This is definitely a bug in Kronolith, not in Thunderbird. Here is why:

The event is created in a local timezone (Europe/Berlin). This 
timezone does not have a fixed offset to UTC, but one that changes 
with DST. That is expected behaviour for ALL local timezones. A 
recurring event in this timezone is expected to start at the same time 
(i.e. 19:00) in both winter and summer. This means that this local 
time converted to UTC is different for this event in winter and summer!

Now Kronolith internally uses UTC to represent the event. That is 
beneficial for many purposes. But the Kronolith developers seemingly 
didn't think about *repeated* events here. If we repeat an event with 
*fixed* time in UTC (every repetition is at 19:00 in UTC), this will 
mean a non-fixed time in local timezones.

By definition of RRULE in RFC 5545 
(https://tools.ietf.org/html/rfc5545#section-3.8.5.3), this is a bug 
in Kronolith. To see this, just look at the examples:

       Every other day - forever:

        DTSTART;TZID=America/New_York:19970902T090000
        RRULE:FREQ=DAILY;INTERVAL=2

        ==> (1997 9:00 AM EDT) September 2,4,6,8...24,26,28,30;
                               October 2,4,6...20,22,24
            (1997 9:00 AM EST) October 26,28,30;
                               November 1,3,5,7...25,27,29;
                               December 1,3,...

-> When DTSTART is given as local time zone, then some events are 
created at 9:00 AM EDT, some at 9:00 AM EST. EDT and EST have a 
different time offset to UTC.

On the other hand, Thunderbird Lightning handles this case correctly: 
when DTSTART is given in UTC, then this means there literally is no 
DST to take care of. The event would happen at 9:00 AM in the chosen 
time (UTC), and will be offset in local time sometimes - and not at 
other times. The RFC is aware of this:
       (...) In most cases, a
       "DTSTART" property of DATE-TIME value type used with a recurrence
       rule, should be specified as a date with local time and time zone
       reference to make sure all the recurrence instances start at the
       same local time regardless of time zone changes.

Note: I believe this bug does not affect some other clients simply 
because they incorrectly implement RFC 5545. When you FIRST convert 
the start time into your local timezone, and THEN apply RRULE to get 
the recurrence set, everything seems fine. And many clients seem to do 
just that, and few people every notice this as a problem because they 
only use one local time anyway, and want this kind of behaviour.

Further note: in Owncloud, this bug does not happen. So SabreDAV (used 
by both OC and Horde) is not responsible.

Create a i.e weekly serial event with thunderbird 24 lightning sync it 
via caldav, the event ist shown with right start and end times in the 
present  in lightning, but in the future ( after time change ) it 
shows timeshit from one hour. Kronolith and Android shows right times 
ever.

here is some additional info with pics

http://sys4.de/de/blog/2013/10/17/serielle-kalender-termine-mit-thunderbird-24-lightning-und-horde-kronolith-caldav-bei-somm-winter-zeit-umstellung/

here is lightning bug report with some more information, guessing 
lightning bug

https://bugzilla.mozilla.org/show_bug.cgi?id=563314

now here is my debug from thunderbird console, what going on at caldav sync

upload

DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20131017T111708Z
LAST-MODIFIED:20131017T111748Z
DTSTAMP:20131017T111748Z
UID:6824a851-a5c8-4b1c-aa66-5da72756d071
SUMMARY:Mo-14-15
RRULE:FREQ=WEEKLY
DTSTART;TZID=Europe/Berlin:20131021T140000
DTEND;TZID=Europe/Berlin:20131021T150000
DESCRIPTION:Mo-14-15
END:VEVENT
END:VCALENDAR
CalDAV: recv:
CalDAV: Item added to robert@schetterer.org successfully

download sync from server

VERSION:2.0
X-WR-CALNAME:Kalender von robert@schetterer.org
PRODID:-//The Horde Project//Horde iCalendar Library//EN
BEGIN:VEVENT
DTSTART:20131021T120000Z
DTEND:20131021T130000Z
DTSTAMP:20131017T111749Z
UID:6824a851-a5c8-4b1c-aa66-5da72756d071
CREATED:20131017T111748Z
LAST-MODIFIED:20131017T111748Z
SUMMARY:Mo-14-15
DESCRIPTION:Mo-14-15
CLASS:PUBLIC
STATUS:CONFIRMED
TRANSP:OPAQUE
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=MO
END:VEVENT
END:VCALENDAR

as thunderbird lightning uploads with

DTSTART;TZID=Europe/Berlin...

in Kronolith sql Europe/Berlin is included for this event

i guess it need this too, when resync from the server
however it might be a lightning bug