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 331375 - change to a different timezone for a specific period
change to a different timezone for a specific period
Status: RESOLVED DUPLICATE of bug 563364
Product: evolution
Classification: Applications
Component: Calendar
2.6.x (obsolete)
Other All
: Normal enhancement
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[timezone]
Depends on:
Blocks:
 
 
Reported: 2006-02-16 06:25 UTC by L. David Baron
Modified: 2009-06-15 17:22 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description L. David Baron 2006-02-16 06:25:23 UTC
Evolution should have user interface for traveling to a different timezone *for
a specific period of time*.  Currently it has a global timezone setting. 
However, this isn't very useful when traveling.  If I'm going to be nine
timezones away for a week, I want to see my events for that week in the timezone
where I'll be in that week; when they're put in the correct timezone they often
don't even show up on the correct day, since the day is different between the
time zones.

For example, I was in Australia from January 28 through February 4 (19 hours
time difference from California).  I want to see the appointments *for the
period when I'm in Australia* in Australia time, no matter what timezone I'm
currently in.  Likewise, for the week I'm in Australia (since I currently change
my global timezone setting when I travel), I want to see the appointments for
when I get back in California time; I don't want my Tuesday meetings showing up
on Wednesday while I'm in Australia.

There are two possible approaches to providing user interface for this that I,
and others that I've discussed this issue with, have thought of:

 1. Provide some out-of-band user interface for specifying a different time zone
for a given time range.

 2. Deduce time zone changes from events that start and end in different
timezones.  You wouldn't necessarily have to do this by default for all events;
there could be a per-event checkbox or a global preference.  However, I think
events that start and end in different timezones are rather rare, and tend to
represent travel.

I strongly prefer solution #2.

If solution #2 is taken, there *may* be some value to warning about unbalanced
travel events, i.e., a situation where the last travel event ends in a
non-default timezone.
Comment 1 André Klapper 2006-02-16 12:20:53 UTC
to me this is NOTABUG - if something like this is useful (and i think so), it should be a desktop (=gnome) wide setting and not a setting per application, because normally the entire computer is in another timezone and not only evolution... ;-)
hmm...comments?
Comment 2 L. David Baron 2006-02-16 15:57:05 UTC
When I travel, the entire computer is in another timezone.  But the point is that when I do that, I don't want evolution to put all my events for all of time in that time zone -- I only want the events for the period when I'm traveling shown in that time zone.

So on February 2, when I was in Australia, I want Evolution to show February 2 in Australia/Sydney, but show February 6 in America/Los_Angeles.
Comment 3 Poornima 2006-02-17 06:03:40 UTC
Good to have this feature, this should be possible I beleive. But not in evolution 2.6.  
Comment 4 André Klapper 2006-02-19 17:33:36 UTC
bug 227902 is a bit similar to this here.
Comment 5 Matthew Barnes 2008-03-11 00:29:27 UTC
Bumping version to a stable release.
Comment 6 Milan Crha 2009-06-15 17:22:47 UTC
I dislike the option of deducting timezone based on the events shown in the calendar, it might be very confusing for ordinary users. Since bug #563364 you can setup second timezone for a day view, and see your appointments in both of them. Main timezone drives the day, the second shows when the event occurs in the second time zone. From my point of view it's more understandable for users than some "on demand foo" from evolution's side.

*** This bug has been marked as a duplicate of 563364 ***