Bug #19173 Appointments for external participants one hour later

[chrigu]

Hi

Today a customer complained that sometimes external participants of an appointment get a wrong calendar entry, which starts one hour later than the original invitation.

After reading the freshly posted Release Notes for Public PTF (2011-05-19) I found a reference to the bug #19173 (see title) which sounds similar to the reported issue.
Unfortunately the bug report is closed for the public and registered users (You are not authorized to access bug...). It would be helpful if this bug could be made public or at least a description could be published, so that I can determine if the customer was hit by this bug or if it's a client problem.

many thanks and regards
Christian

[Markus Wagner]

This is the initial bug report:

Attached is an example appointment invitation created in OX which is displayed one hour later in the externals participants calendar.

The appointment should take place between 11:00-12:00 CEST, but Outlook using OXtender or accepting the appointment in the GUI will show the appointment between 12:00:13:00 CEST.

[chrigu]

Markus, thank you for posting the bug report.

According to the report, this is happening while one accepts an appointment within OX (either via OXtender or web GUI). In our case the time shift happens for external participants without Open-Xchange, participants (Outlook users) which receive an invitation from an Open-Xchange user. So the entry has the wrong time within the external user's calendar, not in OX.

Would you say this is the same bug, or do I have to investigate further on the client side?

Thanks a lot.
Christian

[Tobias Prinz]

We had another bug report for external clients, too, if I remember correctly. This should be similar.

The basic problem is that ICal (RFC 5545) does not specify what timezones to use. They say one should use the TZ/Olson database but do not require it. Therefore, some clients ignore information like TZID=Europe/Berlin because they do not know what Europe/Berlin actually means.

In the mentioned PTF we have added complete timezone definitions for every used timezone. If you want to try out whether that is your problem, too, add a VTIMEZONE definition before importing the appointment and check whether that bug still occurs (*).

That should solve the problem with all kinds of clients.

Still, my interest is piqued: What client are those people using? I had not expected this weird kind of behavior outside of MS Outlook :-)

Kind regards,
Tobias

*) An example timezone for Europe/Berlin (rather ugly, right?):

BEGIN:VTIMEZONE

TZID:Europe/Berlin

TZURL:http://tzurl.org/zoneinfo/Europe/Berlin

X-LIC-LOCATION:Europe/Berlin

BEGIN:DAYLIGHT

TZOFFSETFROM:+0100

TZOFFSETTO:+0200

TZNAME:CEST

DTSTART:19810329T020000

RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU

END:DAYLIGHT

BEGIN:STANDARD

TZOFFSETFROM:+0200

TZOFFSETTO:+0100

TZNAME:CET

DTSTART:19961027T030000

RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU

END:STANDARD

BEGIN:STANDARD

TZOFFSETFROM:+005328

TZOFFSETTO:+0100

TZNAME:CET

DTSTART:18930401T000000

RDATE:18930401T000000

END:STANDARD

BEGIN:DAYLIGHT

TZOFFSETFROM:+0100

TZOFFSETTO:+0200

TZNAME:CEST

DTSTART:19160430T230000

RDATE:19160430T230000

RDATE:19170416T020000

RDATE:19180415T020000

RDATE:19400401T020000

RDATE:19430329T020000

RDATE:19440403T020000

RDATE:19450402T020000

RDATE:19460414T020000

RDATE:19470406T030000

RDATE:19480418T020000

RDATE:19490410T020000

RDATE:19800406T020000

END:DAYLIGHT

BEGIN:STANDARD

TZOFFSETFROM:+0200

TZOFFSETTO:+0100

TZNAME:CET

DTSTART:19161001T010000

RDATE:19161001T010000

RDATE:19170917T030000

RDATE:19180916T030000

RDATE:19421102T030000

RDATE:19431004T030000

RDATE:19441002T030000

RDATE:19451118T030000

RDATE:19461007T030000

RDATE:19471005T030000

RDATE:19481003T030000

RDATE:19491002T030000

RDATE:19800928T030000

RDATE:19810927T030000

RDATE:19820926T030000

RDATE:19830925T030000

RDATE:19840930T030000

RDATE:19850929T030000

RDATE:19860928T030000

RDATE:19870927T030000

RDATE:19880925T030000

RDATE:19890924T030000

RDATE:19900930T030000

RDATE:19910929T030000

RDATE:19920927T030000

RDATE:19930926T030000

RDATE:19940925T030000

RDATE:19950924T030000

END:STANDARD

BEGIN:DAYLIGHT

TZOFFSETFROM:+0200

TZOFFSETTO:+0300

TZNAME:CEMT

DTSTART:19450524T020000

RDATE:19450524T020000

RDATE:19470511T030000

END:DAYLIGHT

BEGIN:DAYLIGHT

TZOFFSETFROM:+0300

TZOFFSETTO:+0200

TZNAME:CEST

DTSTART:19450924T030000

RDATE:19450924T030000

RDATE:19470629T030000

END:DAYLIGHT

BEGIN:STANDARD

TZOFFSETFROM:+0100

TZOFFSETTO:+0100

TZNAME:CET

DTSTART:19460101T000000

RDATE:19460101T000000

RDATE:19800101T000000

END:STANDARD

END:VTIMEZONE

END:VCALENDAR

[chrigu]

Hi Tobias

many thanks for your valuable informations regarding this problem.

In the mentioned PTF we have added complete timezone definitions for every used timezone. If you want to try out whether that is your problem, too, add a VTIMEZONE definition before importing the appointment and check whether that bug still occurs (*).

OK, I will test this with the newest PTF (6.20.0 Rev11) and see if it solves the problem.

Still, my interest is piqued: What client are those people using? I had not expected this weird kind of behavior outside of MS Outlook :-)

Actually the problem happens with MS Outlook

Regards
Christian

[goofy]

hi everyone,

since this exact issue affects us too (appointments imported by external participants appear one hour later - probably related to timezone/daylight saving time interpretation in the generated ical attachment) I was wondering what is the current status of this bug? Has this been fixed in CVS? is the fix in 6.20.0 rev11 ?

thanks and best regards,

guenter

[chrigu]

Yes the issue is fixed with 6.20.0 Rev12.

greetings
Christian