View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001766||SOGo||Web Calendar||public||2012-04-10 08:39||2012-09-04 15:11|
|Fixed in Version||1.3.18|
|Summary||0001766: Time shifts when saving/modifying events in SOGo web interface|
Hi SOGo developers and users!
Sine about November, I have quite a servere problem with the Web Calender in SOGo. When Saving / Modifying events in SOGo web interface, the events (time) shift 2 hours back.
I can always reproduce this problem, The Problem is not a client Problem, was e.g. on http://sogo-demo.inverse.ca everything works fine. It is also not a browser or OS issue. The problem is producable either on Linux with Firefox, or Windows with Chrome, IE9 etc. Must be a server issue...
Also with other clients, the problem is not there. When I connect to the server with my Android Phone via CalDAV or using thunderbird / iceweasel with the plugins (CalDAV) there is no timeshift when saving.
Somehow it must be a timezone problem, but I can not fix it, as the configuration seems to be correct.
I can reproduce the problem on different Debian Systems, even in a clean virtual machine... thought after a new server setup it would work up, but unfortunately it doesn't...
What do you think?
|Tags||No tags attached.|
as you see on the pictures. The time is set correctly, the red line is nearly at 15:00 (3PM) - So, SOGo knows the correct time and timezone.
now I create an event as shown in the first screenshot: 3-5 PM, so after saving, the new event should appear directly under the red line.
Actually it doesn't. The new event is saved with a timeshift - 2 hours back - starting at 1 PM instead of 3 PM
It must be a bug in the saving mechanismn, as now the time-shifted event also appears time shifted on devices connected via CalDAV. (mobile phones etc.)
I can modify the event with the mobile phone or via thunderbird to let it start at 3 PM. This works fine. But in the Web Interface, the event always appears 2 hours back... (e.g. if I move it starting at 5PM - on all CalDAV devices everything is fine, but in the web-interface it shows the event at 3PM.
I am also having this issue. The red line shows the correct time and timezone, but when I save an event in the web interface it shifts back 2 hours (enter 5PM start time -- save -- SOGo web interface shows it at 3PM).
This very well may be a display error, as inspecting the database shows that SOGo is storing the time correctly. In this example I have made an event starting at 5PM - 6PM (1700 - 1800). In the web interface it displays at 3PM, however the database is storing the time correctly. (see Screenshot-1.png)
as the file screen.jpg [^] (44,079 bytes) 2012-04-20 12:32
shows an event which ICS file:
this is also SOGo 1.3.14 on Debian 6.0.4 (32 bit), installed from the packages at the inverse.ca repository
oddly enough, same version of SOGo on the same version of Debian on another installation (different customer) is working properly
both are virtualized the one that fails is under vmware and the one that works is inside an openvz container, I don't think if has anything to do with it, but it's a difference
Carlos, could you spend some time on checking exactly what is different between the two systems? Look at the system timezone, GNUstep packages installed, etc.
Yeah Ludovic, I sure can
Although I will have to get back to you on this next Tuesday, because one of the installations is a closed network testing environment which I can't access from here
I can get a list of Debian Packages, GNUStep packages, timezones, postgresql versions, sope versions, locales ... but what else do you think would be useful?
Thanks a lot for your attention
here mysql, gnustep 1.22.1-2, sope 4.9.r1664.2012, system timezone Europe/Berlin
configuration is the same, issue suddenly occured after a package upgrade (maybe affected by gnustep or sope)
You can easily check the situation on Debian 7 (Wheezy) (you will have to check the issue anyway to keep the code compatible to next debian stable release, ubuntu server etc.)
this is the installation data from the setup that doesn't work properly
sogo @ client-1
root@sogo1-int:~# dpkg -l|grep gnustep
root@sogo1-int:~# dpkg -l|grep sope
root@sogo1-int:~# uname -a
root@sogo1-int:~# dpkg -l|grep postgres
root@sogo1-int:~# dpkg -l|grep tzdata
?xml version="1.0" encoding="UTF-8"?>
this is the installation data from the sogo that does work properly
sogo @ client-2
root@correo:~# dpkg -l|grep gnustep
root@correo:~# uname -a
root@correo:~# dpkg -l|grep postgres
root@correo:~# dpkg -l|grep tzdata
<?xml version="1.0" encoding="UTF-8"?>
when I noticed that one server was using UTC time, I tried changing it to see if it worked properly and it didn't, so I reverted the changes and this is how they are set up at the moment
I am also seeing the problem :
System timezone Europe/Paris (UTC+0200)
Event created on 14h00 appears at 10h00 in the WebUI (and is labelled 10h- in the popup when clicking on it), database entry shows 12h00 for DTSTART
Events created in Lightning show at correct time, database entry correct to.
Event created in Lightning at 14h00 shows at 12h00 in WebUI.
I tried several combinations of SOGoTimeZones and system time zones without making the problem dissapear.
Just recompiled 1.3.17 from sources on Debian, the problem does not occur in the recompiled version. All events are correctly placed and labelled on the WebUI and in Lightning, when created and/or moved. Exact same configuration (and same server) as the previous version (packages from inverse.ca/debian).
How are the .deb available on the inverse.ca/debian repository compiled ?
We will produce shortly packages for Wheezy, so you might want to try this.
Oh Thank you Ludovic !
Problem is solved with that Wheezy Packages! Thank you so much! And all the others cmaldonado and phandaal! (you got the great idea to recompile the sources with the same settings...)
|2012-04-10 08:39||tim_bln||New Issue|
|2012-04-10 08:51||tim_bln||File Added: sogo.png|
|2012-04-10 08:53||tim_bln||File Added: sogo2.png|
|2012-04-10 09:06||tim_bln||Note Added: 0003706|
|2012-04-16 14:56||remd||File Added: Screenshot-1.png|
|2012-04-16 14:57||remd||Note Added: 0003746|
|2012-04-20 12:32||cmaldonado||File Added: screen.jpg|
|2012-04-21 13:50||cmaldonado||Note Added: 0003801|
|2012-04-21 13:52||ludovic||Note Added: 0003802|
|2012-04-21 14:45||cmaldonado||Note Added: 0003804|
|2012-04-25 05:29||tim_bln||Note Added: 0003812|
||Relationship added||related to 0001778|
|2012-04-26 12:28||cmaldonado||Note Added: 0003819|
|2012-04-26 12:29||cmaldonado||Note Edited: 0003819|
|2012-04-26 12:32||cmaldonado||Note Edited: 0003819|
|2012-05-16 01:54||cmaldonado||Note Edited: 0003819|
|2012-08-08 04:17||phandaal||Note Added: 0004296|
|2012-08-08 11:06||phandaal||Note Added: 0004300|
|2012-08-08 11:07||phandaal||Note Edited: 0004296|
|2012-08-21 12:44||ludovic||Note Added: 0004359|
|2012-08-26 13:19||tim_bln||Note Added: 0004379|
|2012-09-04 15:10||francis||Status||new => resolved|
|2012-09-04 15:10||francis||Fixed in Version||=> 1.3.18|
|2012-09-04 15:10||francis||Resolution||open => fixed|
|2012-09-04 15:10||francis||Assigned To||=> francis|
|2013-05-14 04:34||Christian Mack||Relationship added||related to 0002320|