View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001777||SOGo||with SOGo||public||2012-04-25 10:32||2012-11-07 10:24|
|Target Version||2.0.3||Fixed in Version||2.0.2|
|Summary||0001777: Added event in SOGo web interface and it appears shifted one hour in thunderbird+SOGo connector|
The timezone is set to Asia/Jerusalem in all components (Ubuntu, Lightning, .GNUstepDefaults, SOGo web).
All events added from SOGo web interface appear one hour later in the Lightning.
The bug is very similar to http://www.sogo.nu/bugs/view.php?id=180
|Tags||No tags attached.|
In order to provide an ics file, you have to:
I created the Test calendar, an event in it and I see the problem that SOGo does not take DST of the specified timezone into account:
The Asia/Jerusalem is marked as having timezone UTC+2, which is correct for winter time:
Currently we have DST (Daylight Saving Time) in effect, so at the moment the time offset is UTC+3.
This explains why the event is shown in Thunderbird one hour earlier, as if it was filed under UTC+2 conditions.
BTW, the DST switch-over configuration on the SOGo server is correct:
See attached the .ics calendar.
test_created_from_sogo.ics (618 bytes)
BEGIN:VCALENDAR METHOD:PUBLISH VERSION:2.0 PRODID:-//Inverse inc./SOGo 1.3.14//EN BEGIN:VTIMEZONE TZID:Asia/Jerusalem X-LIC-LOCATION:Asia/Jerusalem BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0200 TZNAME:IST DTSTART:19700101T000000 END:STANDARD END:VTIMEZONE BEGIN:VEVENT UID:43D0-4F9EAB00-9-74C62400 SUMMARY:Test 10:00-11:00 DESCRIPTION:Created from SOGo web interface\n CLASS:PUBLIC CREATED:20120430T150846Z DTSTAMP:20120430T150846Z LAST-MODIFIED:20120430T150846Z DTSTART;TZID=Asia/Jerusalem:20120502T090000 DTEND;TZID=Asia/Jerusalem:20120502T100000 TRANSP:OPAQUE END:VEVENT END:VCALENDAR
test_created_from_sogo.ics (618 bytes)
Look at the timezone file included in the sope-cards package.
On my machine I have /usr/share/GNUstep/Libraries/gnustep-base/Versions/1.19/Resources/NSTimeZones/regions file.
It has line "2 Asia/Jerusalem" line. No mention for DST though.
There is no newer gnustep-base-common, albeit gnustep-common is of version 2.2.0-1
I tried to change the file to have "3 Asia/Jerusalem", restarted SOGo, but SOGo still thinks the time offset is UTC+2. How can I change the time offset on the fly? It is production machine with many users. Please help.
Have a look at the timezone files located in /usr/lib/GNUstep/Libraries/Resources/NGCards/TimeZones/
They are included in the "sogo" package in Debian/Ubuntu packages.
Yes, editing the /usr/lib/GNUstep/Libraries/Resources/NGCards/TimeZones/Asia/Jerusalem.ics file helped to temporarily (until the DST reversal) workaround the issue.
I've just regenerated the timezone files using the latest tzdata file from ftp://munnari.oz.au/pub/oldtz/.
I've ran a diff for Asia/Jerusalem and there's no difference.
The last time files were changed over there is at 2006. The db must be obsolete, as in Israel (for example) the DST needs to be adjusted every year (with several months advance notice), as it depends on what ministers decide.
Why can't SOGo take the timezone information from the /usr/share/zoneinfo/* files that are provided by tzdata package? From my experience they are always correct and are updated automatically.
If you look at that file:
It was updated a few days ago.
Perhaps the solution will eventually be to support /usr/share/zoneinfo/* but in the meantime, can you help in finding a source with Olson timezone information that is up-to-date for Asia/Jerusalem?
ftp://ftp.iana.org/tz/ gives me the same data as the link above.
I don't know exact syntax of the tzdata file, but the definitions are looking correctly:
I don't quite understand meaning of "Zion" word in the above snippet. Even more confusing is presence of the following lines in the file:
Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Jerusalem 2:20:56 - LMT 1880
Here is the relevant IST/DST information from the tzdata package:
root@mail:~# zdump -v /usr/share/zoneinfo/Asia/Jerusalem | grep 2011
I am lost here on making any conclusions...
Timezone files have been updated but obviously, no changes were made to Asia/Jerusalem. I'm bumping that ticket to the next release. We might decide to use the OS's zoneinfo in future releases.
Too intrusive for v2.0.0 which is close to be released - bumping to v2.0.1
Could you test again with the next nightly build of SOGo, where the timezone files have been regenerated?
This issue is considered fixed since 2.0.2
|2012-04-25 10:32||skliarie||New Issue|
|2012-04-26 12:40||Christian Mack||Note Added: 0003820|
|2012-04-26 12:43||Christian Mack||Note Edited: 0003820|
|2012-04-30 11:21||skliarie||Note Added: 0003832|
|2012-04-30 11:22||skliarie||File Added: test_created_from_sogo.ics|
|2012-04-30 11:22||skliarie||Note Edited: 0003832|
|2012-04-30 11:24||skliarie||Note Edited: 0003832|
|2012-04-30 11:29||ludovic||Note Added: 0003833|
|2012-04-30 11:55||skliarie||Note Added: 0003834|
|2012-04-30 12:07||ludovic||Note Added: 0003835|
|2012-04-30 13:28||skliarie||Note Added: 0003836|
|2012-04-30 14:20||ludovic||Note Added: 0003837|
|2012-05-01 02:14||skliarie||Note Added: 0003839|
|2012-05-01 02:15||skliarie||Note Edited: 0003839|
|2012-05-01 15:28||ludovic||Note Added: 0003840|
|2012-05-01 15:36||ludovic||Note Added: 0003841|
|2012-05-01 16:16||ludovic||Project||SOGo Connector => SOGo|
|2012-05-01 16:17||ludovic||Product Version||10.0 =>|
|2012-05-01 16:17||ludovic||Target Version||=> 1.3.15|
|2012-05-01 16:45||skliarie||Note Added: 0003842|
|2012-05-09 11:45||ludovic||Note Added: 0003875|
|2012-05-09 11:45||ludovic||Target Version||1.3.15 => 1.3.16|
|2012-05-29 15:58||ludovic||Target Version||1.3.16 => 1.3.17|
|2012-07-16 08:43||ludovic||Target Version||1.3.17 => 1.3.18|
|2012-08-27 11:56||francis||Target Version||1.3.18 => 2.0.0|
|2012-09-24 22:47||ludovic||Note Added: 0004539|
|2012-09-24 22:47||ludovic||Target Version||2.0.0 => 2.0.1|
||Status||new => assigned|
||Assigned To||=> wsourdeau|
||Target Version||2.0.1 => 2.0.2|
||Note Added: 0004680|
||Status||assigned => feedback|
||Target Version||2.0.2 => 2.0.3|
||Note Added: 0004790|
||Status||feedback => resolved|
||Fixed in Version||=> 2.0.2|
||Resolution||open => fixed|