After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 540683 - time zone handling insufficient in GroupWise backend?
time zone handling insufficient in GroupWise backend?
Status: RESOLVED WONTFIX
Product: evolution-groupwise
Classification: Deprecated
Component: Groupwise Plugins/Features
unspecified
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
gnome[unmaintained]
Depends on:
Blocks: 528902
 
 
Reported: 2008-06-28 21:12 UTC by Patrick Ohly
Modified: 2013-07-23 14:39 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Patrick Ohly 2008-06-28 21:12:45 UTC
Bug #528902 only fixed time zone definition collisions in the file and Exchange backend. The GroupWise backend most likely suffers from the same problems, but I don't have access to such an installation and thus can neither test nor fix it.

If someone wants to work on this, have a look at how e_cal_check_timezones() was added to the file backend: http://svn.gnome.org/viewvc/evolution-data-server/branches/gnome-2-22/calendar/backends/file/e-cal-backend-file.c?view=diff&r1=8791&r2=9024&diff_format=h
Comment 1 Patrick Ohly 2008-07-01 08:06:42 UTC
Chenthill wrote in bug #528902:
> Groupwise backend would not need the fix since all the events are
> stored/retrieved in UTC timezone on the server. It always uses the libical
> timezones for the storing the events locally.

Is the backend using UTC without storing any information about the time zone of the event? Is this a limitation of the Evolution backend or Groupwise?

I'm convinced that this mode of operation will lead to wrong conversion to local time in some cases. See: http://www.estamos.de/blog/2008/06/30/calendar-time-stamps-and-time-zones/

In that blog post I'm giving two examples where using UTC without time zone information fails. Please, tell me that I'm wrong (with arguments, please) and that Groupwise doesn't have to be redesigned :-/

If you think that the Groupwise backend handles all of these cases, then a) try it out and b) explain how and why it works.
Comment 2 Chenthill P 2008-07-01 09:07:24 UTC
Sorry I made a mistake in conveying above information. The events are stored with the given timezone.  The items are retrieved in the UTC format. So each event will be stored with a particular timezone associated with it on the server. The client stores only the libical timezones in the cache.
Comment 3 Chenthill P 2008-07-01 09:36:02 UTC
I agree with you on storing the timezone information in cache too. There is not much redesigning needed on groupwise end. Your patch would be need to groupwise provider also. Yes, there would be a case when the timezone suddenly changes where the clients must handle it.  I was thinking much in terms of solving timezone conflicts with your patch. Thanks Patrick for having me rethink on this and ofcourse for your wonderful patch :)

Suman, please make the corresponding changes to the mapi backend too.
Comment 4 André Klapper 2013-07-23 14:39:22 UTC
evolution-groupwise provides connectivity to Novell Groupwise servers. The last stable release of evolution-groupwise was 3.4.2 which took place a year ago.

evolution-groupwise is not under active development anymore.

It is currently unlikely that there will be any further active development.

Closing this report as WONTFIX as part of Bugzilla Housekeeping.

Please feel free to reopen this bug report in the future if anyone takes the responsibility for active development again.