View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003369SOGoWeb Calendarpublic2015-10-16 14:472016-12-30 20:29
Reporterams077 Assigned Toludovic  
PrioritynormalSeverityminorReproducibilityunable to reproduce
Status resolvedResolutionduplicate 
Platform[Server] LinuxOSDebianOS Version7 (Wheezy)
Product Version2.3.2 
Summary0003369: Event showed at wrong time on web calendar
Description

An event was showing at 4pm on the web calendar, whilst other clients were correctly showing it at 3pm. Looking at the raw ics data, 3pm looked correct - I couldn't see any reason for the web calendar to display it at 4pm. The event incorrectly showed at 4pm for both the calendar owner and other users with delegated access to the calendar.

Using the 'copy to my calendar' feature resulted in an event at the correct 3pm time being created on my calendar. An imported crafted event (substituting attendees etc. but using the timezone definitions and event DTSTART and DTEND properties as they are) also displayed at the correct 3pm time.

On the original event, making a trivial change (I unticked the checkbox for sending appointment notifications, and saved it) caused the event to move to the correct 3pm time in the web calendar. Comparing the raw ics before/after this change, only the LAST-MODIFIED property had changed.

Additional Information

Raw ics, with sensitive stuff redacted:

"""
BEGIN:VCALENDAR
PRODID:-//Apple Inc.//Mac OS X 10.10.5//EN
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
DTSTART:19810329T010000
TZNAME:BST
TZOFFSETTO:+0100
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
DTSTART:19961027T020000
TZNAME:GMT
TZOFFSETTO:+0000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
TRANSP:OPAQUE
DTEND;TZID=Europe/London:20151019T160000
ORGANIZER;SENT-BY="MAILTO:<REDACTED>";CN=<REDACTED>
UID:347F-55E9C480-1-640B3B80
DTSTAMP:20150904T162058Z
LOCATION:<REDACTED>
DESCRIPTION:<REDACTED>
SEQUENCE:2
CLASS:PUBLIC
X-SOGO-COMPONENT-CREATED-BY:<REDACTED>
CATEGORIES:aa CONFIRMED
SUMMARY:<REDACTED>
DTSTART;TZID=Europe/London:20151019T150000
LAST-MODIFIED:20150911T132834Z
CREATED:20150904T162058Z
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVI
DUAL;CN=<REDACTED>
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVI
DUAL;CN=<REDACTED>
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVI
DUAL;CN=<REDACTED>
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVI
DUAL;CN=<REDACTED>
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVI
DUAL;CN=<REDACTED>
ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE;CUTYPE=INDIVI
DUAL;CN=<REDACTED>
END:VEVENT
END:VCALENDAR
"""

TagsNo tags attached.

Relationships

Relationship GraphDependency Graph
duplicate of 0003366 closedludovic invitations are shifted one hour in webcalendar 

Activities

Jens Erat

Jens Erat

2015-10-17 12:54

reporter   ~0009013

This is related to 0003369, where the GUI created AND displayed events at a wrong time in the week before switching back to standard time 2015.

http://www.sogo.nu/bugs/view.php?id=3369

After updating to 2.3.2, the events are displayed at the correct, stored time; but the database is not fully normalized: there is the ICS file stored as a text field, and some indexed attributes pulled from that ICS. After the minor modification and storing the event again, the attributes used for fast retrieval which still contained the wrong data from pre-2.3.2 are refreshed from the ICS.

The only way to resolve this is to open and save all events in this particular week; I'm not aware of a method in SOGo to do so (but exporting to a backup and importing again).

You might be successfull touching all the events from CalDAV/WebDAV which might trigger the index updates, but I haven't tried doing so.
ethoms

ethoms

2015-11-19 14:40

reporter   ~0009116

So am I correct in saying this only affects users in timezones that have DST (daylight saving time)?
ethoms

ethoms

2015-11-19 14:44

reporter   ~0009117

So can we close this now as fixed? If Jens Erat is correct, there is not much else we can do. Maybe create a script to correct the existing affected events, but this may cause further damage unless trivial.
ethoms

ethoms

2015-11-19 15:01

reporter   ~0009119

@Jens Erat, I think you meant this is related to 0003366

http://www.sogo.nu/bugs/view.php?id=3366
Jens Erat

Jens Erat

2015-11-20 10:34

reporter   ~0009125

@ethoms: Sure, seems I copied the wrong URI. Didn't want to trap you inside a recursion loop. ;)

I don't think a lot could be done here. A script to correct affected events would have to realize

  • When the event was created
  • Which version of SOGo was ran at that time
  • What client was used (web GUI or CalDAV)

We queried the database for users with events that might be affected and sent a mail to all of them explaining the issue, how the situation can be resolved and asking them to verify all events are at the correct hour (so they don't miss any), and finally apologized for the issue. The feedback (if any) was rather positive, most users just had to verify few events (we notified a month in advance).

By now I wouldn't do anything any more, since the troublesome events should already have already taken place by now, and I'd guess this is subject to closure or merging with 0003366.

Issue History

Date Modified Username Field Change
2015-10-16 14:47 ams077 New Issue
2015-10-17 12:54 Jens Erat Note Added: 0009013
2015-11-19 14:40 ethoms Note Added: 0009116
2015-11-19 14:44 ethoms Note Added: 0009117
2015-11-19 15:01 ethoms Note Added: 0009119
2015-11-20 10:34 Jens Erat Note Added: 0009125
2016-12-30 20:29 ludovic Relationship added duplicate of 0003366
2016-12-30 20:29 ludovic Status new => resolved
2016-12-30 20:29 ludovic Resolution open => duplicate
2016-12-30 20:29 ludovic Assigned To => ludovic