Homepage | Products | OX Knowledge Base | Support | Try Now | Contact | Company
OX Logo
Results 1 to 7 of 7
  1. #1
    Join Date
    Aug 2010
    Location
    Switzerland
    Posts
    18

    Default Bug #19173 Appointments for external participants one hour later

    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

  2. #2
    Join Date
    Feb 2007
    Location
    Dortmund, Germany
    Posts
    168

    Default

    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.
    Markus Wagner
    Open-Xchange Quality Assurance

  3. #3
    Join Date
    Aug 2010
    Location
    Switzerland
    Posts
    18

    Default

    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

  4. #4
    Join Date
    Feb 2007
    Posts
    24

    Default

    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?):
    Code:
    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

  5. #5
    Join Date
    Aug 2010
    Location
    Switzerland
    Posts
    18

    Default

    Hi Tobias

    many thanks for your valuable informations regarding this problem.

    Quote Originally Posted by Tobias Prinz View Post
    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.

    Quote Originally Posted by Tobias Prinz View Post
    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

  6. #6
    Join Date
    Mar 2008
    Posts
    21

    Default

    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

  7. #7
    Join Date
    Aug 2010
    Location
    Switzerland
    Posts
    18

    Default

    Yes the issue is fixed with 6.20.0 Rev12.

    greetings
    Christian

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •