Relationship Graph

Relationship Graph
related to related to child of child of duplicate of duplicate of

View Issue Details

IDProjectCategoryView StatusLast Update
0004894SOGoWeb Calendarpublic2019-12-10 21:16
Reporterondrej.kolin Assigned Tofrancis  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Platform[Server] LinuxOSUbuntuOS Version16.04 LTS
Product Version4.1.1 
Fixed in Version4.2.0 
Summary0004894: Sogo shows event created in external app moved by one hour
Description

Hello, Sogo shows created events moved by one hour.

I've checked the timezone on the server and in the profile, both are setup to Europe/Berlin, which is correct

Steps To Reproduce
  1. Create an event in outlook/evolution
  2. Check the event

Both clients are able to display the event properly.

Additional Information

Event raw data
BEGIN:VCALENDAR
PRODID:-//Inverse inc./SOGo 4.1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
LAST-MODIFIED:20191023T183904Z
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:040000008200E00074C5B7101A82E008000000007048088510A5D501000000000000000
01000000050DC71606CBC1A4C9E96AB50ADED79EF
SUMMARY:Test
TRANSP:OPAQUE
CLASS:PUBLIC
DTSTART;TZID=Europe/Berlin:20191128T133000
DTEND;TZID=Europe/Berlin:20191128T140000
BEGIN:VALARM
TRIGGER;VALUE=DURATION:-PT15M
ACTION:DISPLAY
END:VALARM
LAST-MODIFIED:20191127T095047Z
END:VEVENT
END:VCALENDAR

TagsNo tags attached.

Relationships

related to 0004877 resolvedfrancis Event created with the most recent thunderbird are shifted one hour earlier in the web access and on Smartphone Client (ASync) 

Activities

ondrej.kolin

ondrej.kolin

2019-11-27 10:09

reporter  

screenshots.zip (47,668 bytes)
ondrej.kolin

ondrej.kolin

2019-11-27 13:54

reporter   ~0013928

Moving the event in the event grid works, but the event jumps with the offset.

Even events created in web interface calendar are created with wrong offset. This bug is maybe bigger, than initially thought.

Christian Mack

Christian Mack

2019-11-28 10:42

developer   ~0013930

Which timezone have you set in sogo.conf?

ondrej.kolin

ondrej.kolin

2019-11-28 12:26

reporter   ~0013931

Hi Christian,

SOGoTimeZone = Europe/Berlin;

tfu

tfu

2019-11-28 17:43

reporter   ~0013932

Hi Ondrej,

I'd suggest to check the timezone related info:
timedatectl
cat /etc/timezone
ls -l /etc/localtime
zdump -v /etc/localtime | grep 2019
zdump -v /usr/share/zoneinfo/Europe/Berlin | grep 2019
find / -name Berlin.ics # file content

Regards,
Thomas

ondrej.kolin

ondrej.kolin

2019-11-28 18:28

reporter   ~0013933

I am afraid I am unable to tell if anything is wrong there, therefore sending output of all commands, maybe you can tell me more. I've created a second machine, which is not buggy at all. That confuses me

root@host:/home/administrator# cat /etc/timezone
Europe/Berlin
root@host:/home/administrator# timedatectl
Local time: Thu 2019-11-28 19:24:32 CET
Universal time: Thu 2019-11-28 18:24:32 UTC
RTC time: Thu 2019-11-28 18:24:33
Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no
root@host:/home/administrator# ls -l /etc/localtime
lrwxrwxrwx 1 root root 33 Nov 26 16:28 /etc/localtime -> /usr/share/zoneinfo/Europe/Berlin
root@host:/home/administrator# zdump -v /etc/localtime | grep 2019
/etc/localtime Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 01:59:59 2019 CET isdst=0 gmtoff=3600
/etc/localtime Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 03:00:00 2019 CEST isdst=1 gmtoff=7200
/etc/localtime Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 02:59:59 2019 CEST isdst=1 gmtoff=7200
/etc/localtime Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 02:00:00 2019 CET isdst=0 gmtoff=3600
root@host:/home/administrator# zdump -v /usr/share/zoneinfo/Europe/Berlin | grep 2019
/usr/share/zoneinfo/Europe/Berlin Sun Mar 31 00:59:59 2019 UT = Sun Mar 31 01:59:59 2019 CET isdst=0 gmtoff=3600
/usr/share/zoneinfo/Europe/Berlin Sun Mar 31 01:00:00 2019 UT = Sun Mar 31 03:00:00 2019 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Oct 27 00:59:59 2019 UT = Sun Oct 27 02:59:59 2019 CEST isdst=1 gmtoff=7200
/usr/share/zoneinfo/Europe/Berlin Sun Oct 27 01:00:00 2019 UT = Sun Oct 27 02:00:00 2019 CET isdst=0 gmtoff=3600
root@host:/home/administrator# find / -name Berlin.ics
/usr/lib/GNUstep/Libraries/Resources/NGCards/TimeZones/Europe/Berlin.ics
root@host:/home/administrator# cat /usr/lib/GNUstep/Libraries/Resources/NGCards/TimeZones/Europe/Berlin.ics
BEGIN:VCALENDAR
PRODID:-//Inverse inc.//NONSGML IANA 2019c//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
LAST-MODIFIED:20191023T183904Z
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

ludovic

ludovic

2019-11-28 18:29

administrator   ~0013934

That's the output on the buggy machine or the working one?

ondrej.kolin

ondrej.kolin

2019-11-29 11:57

reporter   ~0013937

That's the buggy one.

I found out, that even events created in webmail calendar get moved:

(video of that) https://ctrlv.tv/4wvT

tfu

tfu

2019-11-29 14:46

reporter   ~0013938

Check for any difference, if not already done, between both server:
installed packages: apt list -installed
timezone setup (as above)
ls -l /usr/share/GNUstep/Libraries/gnustep-base/Versions/<version>/Resources/NSTimeZones

How does the raw-data of the event created in the video looks like?
Check the quick-table in the database:
select * from sogo_quick_appointment where c_title = '<event name>';

ondrej.kolin

ondrej.kolin

2019-11-29 16:16

reporter   ~0013939

Event data:
https://paste.gnome.org/prnahkmzw
Configuration of timezones as requested host2 is the correct one:
https://paste.gnome.org/ph01a1l1t

tfu

tfu

2019-11-29 17:20

reporter   ~0013940

I'd suggest to compare all installed packages.

tfu

tfu

2019-11-29 20:25

reporter   ~0013941

What I find confusing is that you opened the bug for 16.04 TLS but have gnustep 1.25? I'm able to reproduce what you described when I mess around and run xenial sogo/sope packages with gnustep-base-common 1.25.1-2.

Please show the output of:
apt list --installed | grep gnustep

ondrej.kolin

ondrej.kolin

2019-12-02 09:02

reporter   ~0013944

Sorry guys, the Ubuntu is 18.04, that is my mistake.

ondrej.kolin

ondrej.kolin

2019-12-02 10:27

reporter   ~0013946

DPKG --list | grep ^ii | awk '{print $2 $3}'
This one works (used before for some testing and debugging, so the diff is not that easy):
https://paste.gnome.org/ptqhoo8qz
This one does not work:
https://paste.gnome.org/pwdpr5gh9

tfu

tfu

2019-12-02 18:44

reporter   ~0013948

Above links are broken.
->check for differences with installed gnustep packages

ondrej.kolin

ondrej.kolin

2019-12-03 14:26

reporter   ~0013949

First server (not working)
https://pastebin.com/KJjgV0x0
Second one (working, contains more packages as we debug some SOGo issue we had before)
https://pastebin.com/4qLFrgNE

Christian Mack

Christian Mack

2019-12-04 08:45

developer   ~0013950

Just as Info.
I made a diff.
In that I see that the working machine has the following gnustep packages not on the defect machine:

gnustep-back-common 0.26.2-3
gnustep-back0.26 0.26.2-3
gnustep-back0.26-cairo 0.26.2-3
gnustep-base-doc 1.25.1-2ubuntu3
gnustep-core-devel 7.9
gnustep-core-doc 7.9
gnustep-devel 7.9
gnustep-dl2-postgresql-adaptor 0.12.0-15.1build2
gnustep-gui-common 0.26.2-3
gnustep-gui-doc 0.26.2-3
gnustep-gui-runtime 0.26.2-3
gnustep-icons 1.0-6
gnustep-make-doc 2.7.0-3
libgnustep-base-dev 1.25.1-2ubuntu3
libgnustep-base1.25-dbgsym 1.25.1-2ubuntu3
libgnustep-dl2-0d 0.12.0-15.1build2
libgnustep-dl2-dev 0.12.0-15.1build2
libgnustep-gui-dev 0.26.2-3
libgnustep-gui0.26 0.26.2-3

Also I see the following packages on the working machine, missing on the defect one:

sope4.9-appserver 4.9.r1664.20191108
sope4.9-dbg 4.9.r1664.20191108
sope4.9-gdl1-postgresql 4.9.r1664.20191108

tfu

tfu

2019-12-06 21:07

reporter   ~0013956

I still think this is caused by a broken gnustep installation.
Compare following directories between working and non-working server:
ls -lR /usr/share/GNUstep/Libraries/gnustep-base/Versions/1.25/Resources
ls -lR /usr/share/GNUstep/Libraries/gnustep-base/Versions/1.25/Resources/NSTimeZones

ludovic

ludovic

2019-12-09 17:29

administrator   ~0013961

Try the current nightly build.

ondrej.kolin

ondrej.kolin

2019-12-10 08:39

reporter   ~0013962

I did an upgrade and it works now! MAGIC

Just kidding. Thanks, issue can be closed

francis

francis

2019-12-10 12:24

administrator   ~0013966

https://github.com/inverse-inc/sogo/commit/2e46e89d58d75f15d931b3664b12b674bfae6453

Issue History

Date Modified Username Field Change
2019-11-27 10:09 ondrej.kolin New Issue
2019-11-27 10:09 ondrej.kolin File Added: screenshots.zip
2019-11-27 13:54 ondrej.kolin Note Added: 0013928
2019-11-28 10:42 Christian Mack Note Added: 0013930
2019-11-28 12:26 ondrej.kolin Note Added: 0013931
2019-11-28 17:43 tfu Note Added: 0013932
2019-11-28 18:28 ondrej.kolin Note Added: 0013933
2019-11-28 18:29 ludovic Note Added: 0013934
2019-11-29 11:57 ondrej.kolin Note Added: 0013937
2019-11-29 14:46 tfu Note Added: 0013938
2019-11-29 16:16 ondrej.kolin Note Added: 0013939
2019-11-29 17:20 tfu Note Added: 0013940
2019-11-29 20:25 tfu Note Added: 0013941
2019-12-02 09:02 ondrej.kolin Note Added: 0013944
2019-12-02 10:27 ondrej.kolin Note Added: 0013946
2019-12-02 18:44 tfu Note Added: 0013948
2019-12-03 14:26 ondrej.kolin Note Added: 0013949
2019-12-04 08:45 Christian Mack Note Added: 0013950
2019-12-06 21:07 tfu Note Added: 0013956
2019-12-09 17:29 ludovic Note Added: 0013961
2019-12-10 08:39 ondrej.kolin Note Added: 0013962
2019-12-10 12:24 francis Assigned To => francis
2019-12-10 12:24 francis Status new => resolved
2019-12-10 12:24 francis Resolution open => fixed
2019-12-10 12:24 francis Fixed in Version => 4.2.0
2019-12-10 12:24 francis Note Added: 0013966
2019-12-10 21:16 francis Relationship added related to 0004877