[horde] kronolith off-by-one-hour daylight savings time bug

[Benjamin Rose]

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 at 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 at 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.

Michael, does all of this look like it should be working to you? I will 
update ticket 12773 with my most recent findings.

Thanks,
Ben

On 03/05/2014 10:57 AM, Benjamin Rose wrote:
> Hi,
>
> I have collected as much information as I can right now and have
> attached it to the relevant ticket:
>
> http://bugs.horde.org/ticket/12773
>
> The ics file I attached last is the most telling I think - evolution,
> lightning, and google calendar (!) all show the event 2pm this week
> (week of 3/3/2014) and scheduled at 3pm next week (week of 3/10/2014),
> after the DST switch. This data is coming from kronolith somehow, but
> I'm not pro enough yet to figure out what exactly is malformed about it.
> Reading up on ics formatting now.
>
> If there's any additional information that would be of help in
> diagnosing this problem, please don't hesitate to ask.
>
> Thanks,
> Ben
>
> On 03/04/2014 06:08 PM, Michael J Rubinsky wrote:
>>
>> Quoting Benjamin Rose <benrose at math.princeton.edu>:
>>
>>> No, this problem exists with not only lightning but also evolution,
>>
>> Just tried this with evolution as well, and I still don't see this using
>> either stable code or Git master.
>>
>>> and outlook, regardless of client operating system. The bug is within
>>> horde, not the subscribers. I don't think bringing in lightning devs
>>> will help here.
>>>
>>> Michael, would it be sufficient for you if I create you an account on
>>> my Horde installation and you can witness the problem first-hand? I
>>> will email you off-list.
>>
>>
>> Not really. The problem isn't that I don't believe that YOU are seeing
>> it, but rather that I, or some other developer, needs this to happen on
>> a development machine that we can actively debug it locally on -
>> including adding debug code, xdebug breakpoints etc...
>>
>>
>>