In order to provide an ics file, you have to:

• create an additional calendar in SOGo
• move both events you try to report into this new calendar
  If this doesn't work or changes the effect you try to show, create them in
  this new calendar in the first place
• export the new calendar

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:
TZOFFSETFROM:+0200
TZOFFSETTO:+0200

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:
zdump -v /etc/localtime |grep 2012
/etc/localtime Thu Mar 29 23:59:59 2012 UTC = Fri Mar 30 01:59:59 2012 IST isdst=0 gmtoff=7200
/etc/localtime Fri Mar 30 00:00:00 2012 UTC = Fri Mar 30 03:00:00 2012 IDT isdst=1 gmtoff=10800
/etc/localtime Sat Sep 22 22:59:59 2012 UTC = Sun Sep 23 01:59:59 2012 IDT isdst=1 gmtoff=10800
/etc/localtime Sat Sep 22 23:00:00 2012 UTC = Sun Sep 23 01:00:00 2012 IST isdst=0 gmtoff=7200

See attached the .ics calendar.

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.
It is provided by debian package gnustep-base-common (version 1.19.3-1ubuntu1).

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:

ftp://munnari.oz.au/pub/oldtz/tzdata2012c.tar.gz

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:
Rule Zion 2011 only - Apr 1 2:00 1:00 D
Rule Zion 2011 only - Oct 2 2:00 0 S
Rule Zion 2012 2015 - Mar Fri>=26 2:00 1:00 D
Rule Zion 2012 only - Sep 23 2:00 0 S

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
2:20:40 - JMT 1918 # Jerusalem Mean Time?
2:00 Zion I%sT

Here is the relevant IST/DST information from the tzdata package:

root@mail:~# zdump -v /usr/share/zoneinfo/Asia/Jerusalem | grep 2011
/usr/share/zoneinfo/Asia/Jerusalem Thu Mar 31 23:59:59 2011 UTC = Fri Apr 1 01:59:59 2011 IST isdst=0 gmtoff=7200
/usr/share/zoneinfo/Asia/Jerusalem Fri Apr 1 00:00:00 2011 UTC = Fri Apr 1 03:00:00 2011 IDT isdst=1 gmtoff=10800
/usr/share/zoneinfo/Asia/Jerusalem Sat Oct 1 22:59:59 2011 UTC = Sun Oct 2 01:59:59 2011 IDT isdst=1 gmtoff=10800
/usr/share/zoneinfo/Asia/Jerusalem Sat Oct 1 23:00:00 2011 UTC = Sun Oct 2 01:00:00 2011 IST isdst=0 gmtoff=7200
root@mail:~#
root@mail:~# zdump -v /usr/share/zoneinfo/Asia/Jerusalem | grep 2012
/usr/share/zoneinfo/Asia/Jerusalem Thu Mar 29 23:59:59 2012 UTC = Fri Mar 30 01:59:59 2012 IST isdst=0 gmtoff=7200
/usr/share/zoneinfo/Asia/Jerusalem Fri Mar 30 00:00:00 2012 UTC = Fri Mar 30 03:00:00 2012 IDT isdst=1 gmtoff=10800
/usr/share/zoneinfo/Asia/Jerusalem Sat Sep 22 22:59:59 2012 UTC = Sun Sep 23 01:59:59 2012 IDT isdst=1 gmtoff=10800
/usr/share/zoneinfo/Asia/Jerusalem Sat Sep 22 23:00:00 2012 UTC = Sun Sep 23 01:00:00 2012 IST isdst=0 gmtoff=7200
root@mail:~#

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

Hi Arie,

Could you test again with the next nightly build of SOGo, where the timezone files have been regenerated?

Thank you.

This issue is considered fixed since 2.0.2