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.

Which timezone have you set in sogo.conf?

Hi Christian,

SOGoTimeZone = Europe/Berlin;

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

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

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

That's the buggy one.

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

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

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>';

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

I'd suggest to compare all installed packages.

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

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

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

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

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

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

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

Try the current nightly build.

I did an upgrade and it works now! MAGIC

Just kidding. Thanks, issue can be closed

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