Bug 208709 - clock applet has two places to set UTC, confusing
clock applet has two places to set UTC, confusing
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: gnome-applets (Show other bugs)
rawhide
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-30 12:02 EDT by Jason
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-30 14:05:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason 2006-09-30 12:02:36 EDT
Description of problem:
I have the Sept 30th rawhide running.  When I startx the clock applet shows the
wrong time.  If I goto a terminal prompt and run date the proper time is
displayed.  The time the applet shows is 5 hours into the future.  The timezone
is Central which is 5 hours behing GMT.  

Version-Release number of selected component (if applicable):
gnome-applets-2.16.0.1-6.fc6.i386.rpm

How reproducible:
always

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jason 2006-10-09 19:10:36 EDT
A reinstall of rawhide fixed the problem.  Part of the problem is there are two
places where you can set UNC, in set date/time in the timezone tab and the
prefereneces.  Maybe having two spots is the correct thing, I don't know, but it
is confusing.
Comment 2 Ray Strode [halfline] 2007-03-30 14:05:15 EDT
I agree it's not ideal.  I think that one of the checkboxes is whether or not
the system is configured for UTC and the other is a user preference.

We could just make a choice and say that system should always be utc and users
can set their offsets from that.

Unfortunately, there is no way to store a timezone in the bios, so making that
kind of policy decision would break dual boot users.

Anyway, it's a hard problem, that we'll have to fix at some point, but probably
aren't going to tackle right now, so I'm going to close this bug.

I'm glad you got things figure out, though.

Note You need to log in before you can comment on or make changes to this bug.