Dependency Graph

View IssueRelationship GraphVerticalShow Summary
Dependency Graph
related to related to child of child of duplicate of duplicate of

View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0003024SOGoWeb Calendarpublic2014-12-12 19:072017-06-18 07:48
Reporteraccumulator Assigned Toludovic  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionreopened 
Platform[Server] LinuxOSDebianOS Version7 (Wheezy)
Product Version2.2.11a 
Summary0003024: Web Calendar shows events time-shifted
Description

I have 3 clients, KDE/Kontact, a N9 and a Jolla phone.

I can sync events through SOGo and the appointment will appear on the same time on all devices (as long as I keep them on the same timezone, but that's another story).

The Web Calendar however shows these appointments completely off, shifting not only many hours, but also 28 minutes.

eg:

event1
N9: 20:30
jolla: 20:30
kontact: 20:30
web calendar: 01:58

event2
N9: 21:00
jolla: 21:00
kontact: 21:00
web calendar: 02:28

Also, when upgrading from 2.2.10 to 2.2.11a (before the above tests), my existing appointments shifted to one day earlier in the web calendar!

TagsNo tags attached.

Relationships

Relationship GraphDependency Graph
duplicate of 0002179 new Missing RDATE support in timezones 

Activities

Christian Mack

Christian Mack

2014-12-15 14:28

developer   ~0007837

Which timezone do you use?
ludovic

ludovic

2015-01-09 13:48

administrator   ~0008026

No feedback provided in weeks, closing.
accumulator

accumulator

2015-04-04 08:18

reporter   ~0008390

sorry, didn't notice the request for additional information.

timezone is Europe/Amsterdam by default in all devices and sogo
accumulator

accumulator

2015-04-04 08:25

reporter   ~0008391

I've done a bit more testing with Jolla/SyncEvo and Sogo.

If I create an event in either the Jolla or Sogo, the event is shifted 1 hour to the future on the other.

  1. new event created on Jolla, 09:00, implicit (default) TZ is Europe/Amsterdam
  2. new event created on Sogo, 11:00, implicit (default) TZ is Europe/Amsterdam

(1) shows in Sogo/Web at 10:00
(2) shows in Jolla at 12:00

in database:

(1)
BEGIN:VCALENDAR
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.47//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
BEGIN:STANDARD
DTSTART:19671029T030000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:19870329T020000
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-1SU
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
LAST-MODIFIED:20150404T073616Z
DTSTAMP:20150404T073649Z
CREATED:20150404T073616Z
UID:0b857f56-6cd8-4e29-811a-1c367d311720
TRANSP:OPAQUE
SUMMARY:Test3
LOCATION:Jolla
DTSTART;TZID=Europe/Amsterdam:20150404T090000
DTEND;TZID=Europe/Amsterdam:20150404T100000
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

(2)
BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 2.2.17a//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
X-LIC-LOCATION:Europe/Amsterdam
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:421A-551F9880-7-696AFB00
SUMMARY:Test5
LOCATION:Sogo
CLASS:PUBLIC
CREATED:20150404T075412Z
DTSTAMP:20150404T075412Z
LAST-MODIFIED:20150404T075412Z
DTSTART;TZID=Europe/Amsterdam:20150404T110000
DTEND;TZID=Europe/Amsterdam:20150404T120000
TRANSP:OPAQUE
END:VEVENT
END:VCALENDAR
accumulator

accumulator

2015-04-04 09:02

reporter   ~0008392

I also just synced to the N9:

(1) shows in N9 at 09:00 (correct)
(2) shows in N9 at 11:00 (correct)

Adding then a new event in the N9:

  1. new event created on N9, 16:00, implicit (default) TZ is Europe/Amsterdam

and syncing yields:

(3) shows in Sogo at 16:40, shows in Jolla at 17:00

BEGIN:VCALENDAR
PRODID:-//K Desktop Environment//NONSGML libkcal 4.3//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Amsterdam
BEGIN:DAYLIGHT
TZNAME:NST
TZOFFSETFROM:+001932
TZOFFSETTO:+011932
DTSTART:19160501T234028
RDATE;VALUE=DATE-TIME:19160501T234028
RDATE;VALUE=DATE-TIME:19170417T014028
RDATE;VALUE=DATE-TIME:19180402T014028
RDATE;VALUE=DATE-TIME:19190408T014028
RDATE;VALUE=DATE-TIME:19200406T014028
RDATE;VALUE=DATE-TIME:19210405T014028
RDATE;VALUE=DATE-TIME:19220327T014028
RDATE;VALUE=DATE-TIME:19230602T014028
RDATE;VALUE=DATE-TIME:19240331T014028
RDATE;VALUE=DATE-TIME:19250606T014028
RDATE;VALUE=DATE-TIME:19260516T014028
RDATE;VALUE=DATE-TIME:19270516T014028
RDATE;VALUE=DATE-TIME:19280516T014028
RDATE;VALUE=DATE-TIME:19290516T014028
RDATE;VALUE=DATE-TIME:19300516T014028
RDATE;VALUE=DATE-TIME:19310516T014028
RDATE;VALUE=DATE-TIME:19320523T014028
RDATE;VALUE=DATE-TIME:19330516T014028
RDATE;VALUE=DATE-TIME:19340516T014028
RDATE;VALUE=DATE-TIME:19350516T014028
RDATE;VALUE=DATE-TIME:19360516T014028
RDATE;VALUE=DATE-TIME:19370523T014028
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:AMT
TZOFFSETFROM:+011932
TZOFFSETTO:+001932
DTSTART:19161001T224028
RDATE;VALUE=DATE-TIME:19161001T224028
RDATE;VALUE=DATE-TIME:19170918T024028
RDATE;VALUE=DATE-TIME:19181001T024028
RDATE;VALUE=DATE-TIME:19190930T024028
RDATE;VALUE=DATE-TIME:19200928T024028
RDATE;VALUE=DATE-TIME:19210927T024028
RDATE;VALUE=DATE-TIME:19221009T024028
RDATE;VALUE=DATE-TIME:19231008T024028
RDATE;VALUE=DATE-TIME:19241006T024028
RDATE;VALUE=DATE-TIME:19251005T024028
RDATE;VALUE=DATE-TIME:19261004T024028
RDATE;VALUE=DATE-TIME:19271003T024028
RDATE;VALUE=DATE-TIME:19281008T024028
RDATE;VALUE=DATE-TIME:19291007T024028
RDATE;VALUE=DATE-TIME:19301006T024028
RDATE;VALUE=DATE-TIME:19311005T024028
RDATE;VALUE=DATE-TIME:19321003T024028
RDATE;VALUE=DATE-TIME:19331009T024028
RDATE;VALUE=DATE-TIME:19341008T024028
RDATE;VALUE=DATE-TIME:19351007T024028
RDATE;VALUE=DATE-TIME:19361005T024028
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:NEST
TZOFFSETFROM:+011932
TZOFFSETTO:+0120
DTSTART:19370701T224028
RDATE;VALUE=DATE-TIME:19370701T224028
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:NET
TZOFFSETFROM:+0120
TZOFFSETTO:+0020
DTSTART:19371004T024028
RDATE;VALUE=DATE-TIME:19371004T024028
RDATE;VALUE=DATE-TIME:19381003T024000
RDATE;VALUE=DATE-TIME:19391009T024000
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:NEST
TZOFFSETFROM:+0020
TZOFFSETTO:+0120
DTSTART:19380516T014000
RDATE;VALUE=DATE-TIME:19380516T014000
RDATE;VALUE=DATE-TIME:19390516T014000
END:DAYLIGHT
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0020
TZOFFSETTO:+0200
DTSTART:19400516T234000
RDATE;VALUE=DATE-TIME:19400516T234000
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19790930T030000
RRULE:FREQ=YEARLY;COUNT=17;BYMONTH=9;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19421103T024000
RDATE;VALUE=DATE-TIME:19421103T024000
RDATE;VALUE=DATE-TIME:19431004T020000
RDATE;VALUE=DATE-TIME:19441002T020000
RDATE;VALUE=DATE-TIME:19450916T020000
RDATE;VALUE=DATE-TIME:19770925T030000
RDATE;VALUE=DATE-TIME:19781001T030000
END:STANDARD
BEGIN:DAYLIGHT
TZNAME:CEST
accumulator

accumulator

2015-06-15 09:30

reporter   ~0008640

ping
accumulator

accumulator

2015-08-02 09:26

reporter   ~0008797

any more information needed??
vascorppor

vascorppor

2015-09-01 08:23

reporter   ~0008879

Dear all,

I can confirm this issue. I have just been called by my doctor's office to reschedule an appointment. To my surprise, sogo web interface has indeed shown a wrong time (10:00 instead of 09:00). MS Outlook and Android, however, displayed the appointment correctly. The source code of the wrongly displayed appointment is as follows:

BEGIN:VCALENDAR
PRODID:-//dmfs.org//mimedir.icalendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20151020T090000
SUMMARY:DataRemoved
TRANSP:OPAQUE
STATUS:CONFIRMED
DTEND;TZID=Europe/Berlin:20151020T100000
LAST-MODIFIED:20150811T072804Z
DTSTAMP:20150811T072804Z
CREATED:20150811T072804Z
UID:f768eb19-f45c-41ed-8cba-a14cd46374c7.1439278084728
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

Following the reschedule (again using Android via dmfs) resulted in the following source code:

BEGIN:VCALENDAR
PRODID:-//dmfs.org//mimedir.icalendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20150811T072804Z
DTSTART;TZID=Europe/Berlin:20151013T094500
SUMMARY:DataRemoved
TRANSP:OPAQUE
STATUS:CONFIRMED
DTEND;TZID=Europe/Berlin:20151013T110000
LAST-MODIFIED:20150901T080754Z
DTSTAMP:20150901T080754Z
SEQUENCE:1
UID:f768eb19-f45c-41ed-8cba-a14cd46374c7.1439278084728
CLASS:PUBLIC
END:VEVENT
END:VCALENDAR

The latter appointment is displayed correctly. The time zone is set correctly in sogo to Europe/Berlin.

This is a flaw with serious implications on users relying on sogo.

Kind regards,
Martin
accumulator

accumulator

2017-06-16 13:19

reporter   ~0011956

I guess the 'reopened' status is not watched by the developers...
ludovic

ludovic

2017-06-16 15:26

administrator   ~0011964

Can you reproduce the issue in a reliable way?

If so, provide us the full procedure with a sample ICS.

Thanks!
accumulator

accumulator

2017-06-18 07:29

reporter   ~0011983

Last edited: 2017-06-18 07:48

I have no idea what else you need, everything I did is described above, including the raw sources. The original report is on SOGo 2.2.11a, however I see similar (same?) behaviour on my current 3.0 install.

Can you give an indication where you think the problem lies, so I can analyze this better myself?

Is the received raw calendar event source transformed by SOGo when receiving, storing or transmitting, or is it used as initially received always?

If it is not transformed by SOGo, then the time presentation is derived from the various TZ, RDATE and RRULE fields, correct? Does this local-time determination then also interact with the tzdata package installed?

I'm trying to establish which client in this whole story makes some interpretation error, but I'm too unfamiliar with the standard to spot either a problem in the generated source, or the interpretation of it..

Issue History

Date Modified Username Field Change
2014-12-12 19:07 accumulator New Issue
2014-12-15 14:28 Christian Mack Note Added: 0007837
2015-01-09 13:48 ludovic Note Added: 0008026
2015-01-09 13:48 ludovic Status new => resolved
2015-01-09 13:48 ludovic Resolution open => suspended
2015-01-09 13:48 ludovic Assigned To => ludovic
2015-04-04 08:18 accumulator Note Added: 0008390
2015-04-04 08:18 accumulator Status resolved => feedback
2015-04-04 08:18 accumulator Resolution suspended => reopened
2015-04-04 08:25 accumulator Note Added: 0008391
2015-04-04 08:25 accumulator Status feedback => assigned
2015-04-04 09:02 accumulator Note Added: 0008392
2015-06-15 09:30 accumulator Note Added: 0008640
2015-08-02 09:26 accumulator Note Added: 0008797
2015-08-03 07:49 Christian Mack Relationship added duplicate of 0002179
2015-09-01 08:23 vascorppor Note Added: 0008879
2016-12-21 17:48 ludovic Severity major => minor
2017-06-16 13:19 accumulator Note Added: 0011956
2017-06-16 15:26 ludovic Note Added: 0011964
2017-06-18 07:29 accumulator Note Added: 0011983
2017-06-18 07:33 accumulator Note Edited: 0011983
2017-06-18 07:47 accumulator Note Edited: 0011983
2017-06-18 07:48 accumulator Note Edited: 0011983