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

Wed Mar 5 23:35:03 UTC 2014

Ok, I've found the source of the problem and documented it in the same 
ticket:

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

Robert, with these findings you should be able to fix the issue in your 
installation.

But Michael, I need some advice in writing a patch to permanently fix 
the issue for security-minded people with their webservers running 
SELinux and/or bounded by a restrictive firewall. I want to be able to 
load the tzdata in manually, which doesn't seem to currently work for me 
with a file:/// URI as defined in kronolith/config/conf.php. Please 
check out my full documentation in that ticket and let me know.

Perhaps also instead of downloading the tzdata and caching it for a week 
we could make use of a package like:

http://pecl.php.net/package/timezonedb

to keep the data updated. But again I'm not sure the best route, 
something in a PEAR module with the rest of the horde stuff and a proper 
dependency chain would probably be best, no?

Thanks,
Ben

On 03/05/2014 02:29 PM, Benjamin Rose wrote:
> 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...
>>>
>>>
>>>