0003369: Event showed at wrong time on web calendar - SOGo | BTS

ID	Project	Category	View Status	Date Submitted	Last Update
0003369	SOGo	Web Calendar	public	2015-10-16 14:47	2016-12-30 20:29

Reporter	ams077	Assigned To	ludovic
Priority	normal	Severity	minor	Reproducibility	unable to reproduce
Status	resolved	Resolution	duplicate
Platform	[Server] Linux	OS	Debian	OS Version	7 (Wheezy)
Product Version	2.3.2

Summary	0003369: 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 """
Tags	No tags attached.

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 `touch`ing all the events from CalDAV/WebDAV which might trigger the index updates, but I haven't tried doing so.

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

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