no, because it can happen that you're in another timezone when travelling with your laptop.

So if I travel to another timezone, I should change my Evolution timezone and do not change my system timezone?

When I am *planning* travel to another time zone, it is convenient to be able to switch Evolution to that time zone without switching my whole laptop to that time zone.

Please do NOT change current behavior. It is fine the way it is, and if it worked the way OP requested, I would call it a bug.

If Evolution retains the ability to choose a custom time zone, it should still use the system time zone information instead of its own internal copy - that way if the distro updates system time zone info when Evolution hasn't, things don't get out of sync

I think (hope) that what the OP was asking was for Evolution to use the timezone information from the system, rather than having its own complete (incompatible) copy of timezone data--especially since the Evolution version is constantly out of date!

Whether Evo uses the actual timezone settings from the system or not is another question; I agree it would be nice to have Evo initialize the timezone settings from the system rather than asking the user when it first comes up, but it should be possible to change Evo's settings without changing the system settings.

But that doesn't have anything to do with where Evo gets timezone info from.

This is probably best marked as a duplicate of bug #301363

I would probably be optimal, if we had two settings:
- use system time zone (and use it as a default and not bother everyone when doing initial setup)
- use evolution specific time zone for those who prefer it

Andre: now, when we have the shiny new clock applet, you can easy switch between timezones within it.

Pavel, when you change system timezone with the international clock applet, this doesn't change the timezone in Evolution (at least for me on Hardy RC). I consider this a bug. I realise Crispin would consider it a bug if Evolution changed with his system timezone, but I suspect the majority of people would prefer it to change with the system timezone. 

I think the solution as mentioned would be to have two settings, one to set a timezone manually, and one to sync it to whatever the system time is.

Integration with system time zone had been done in Evolution 2.12. Can we close the bug ?  TIA.

what do you call system timezone integration? GNOME 2.22 still had this issue, reopening the bug

I can confirm that 2.22 still has this issue.  Now that the clock applet allows you to change zones quicker and more efficiently that evolution, this "feature" is not only redundant, but potentially dangerous.  An individual that isn't familiar with TZ under evolution will miss appointments after changing the system TZ, assuming that all applications will get the change.

Created attachment 131711 [details] [review]
proposed eds patch

for evolution-data-server;

Most of this code is based on gnome-panel's clock-applet's system-timezone.c.
New API functions included.

Created attachment 131714 [details] [review]
proposed evo patch

for evolution;

evolution's part. No timezone configuration in the first setup wizard for a timezone, sets "use system timezone" instead. Added some widgets to be able to check/uncheck this in preferences.
Two things:
- I do not know how to listen for system timezone change
- I noticed some similar behaviour like in bug #573866 when
  checking/unchecking "quickly". I do not know why.

Once the 'Use system timezone' option is enabled, it would be good to set the existing gconf key "/apps/evolution/calendar/display/timezone" to system timezone. I say this since all the components watch for changes in this key.

Marcus banes line shows a wrong time when i select this option, though both my system timezone and timezone set in evolution are the same. I suspect this might be fixed by setting the above gconf key. 

The Checkbox for 'Use system timezone' could come under Timezone  combo for better alignment. The current alignment does not look so good. 

All the EDS changes seems fine. The evolution part needs to be looked a bit so the timezone changes propogates well.

Would it better to watch for the changes in /etc/locatime file? Am not sure, need to think about the best way.

(In reply to comment #14)
> Once the 'Use system timezone' option is enabled, it would be good to set the
> existing gconf key "/apps/evolution/calendar/display/timezone" to system
> timezone. I say this since all the components watch for changes in this key.

I didn't want to do this, rather have it easier for users to have their timezone remembered, thus when unchecking "use system timezone" they will not be forced to find the timezone again.

> Marcus banes line shows a wrong time when i select this option, though both my
> system timezone and timezone set in evolution are the same. I suspect this
> might be fixed by setting the above gconf key. 

I'll look at this.

> The Checkbox for 'Use system timezone' could come under Timezone  combo for
> better alignment. The current alignment does not look so good. 

The way I ordered it is by preference/logic, because the combo doesn't influence checkbox, but checkbox influences combo.

Created attachment 132684 [details] [review]
proposed evo patch ][

for evolution;

Moved "time zone" label one row up, instead of changing order of the checkbox an the combo.

Checked the Marcus Bain line issue, and it doesn't happen to me always, but as I thought, it's the issue of bug #573866. When I add debug prints to read and write functions of use_system_timezone, then I see I wrote TRUE, but the next read returned FALSE or vice versa. Usually works fine, though.

Also added calendar_config_get_timezone_stored, which returns the timezone stored in a gconf, so the preferences dialog will show the timezone which is stored, not the one actually in use.

Please commit the patches to trunk.

Created commit 3ea36b6 in eds master.
Created commit c33335b in evo master.

*** Bug 251361 has been marked as a duplicate of this bug. ***

*** Bug 574219 has been marked as a duplicate of this bug. ***