Bug 208709

Summary: clock applet has two places to set UTC, confusing
Product: [Fedora] Fedora Reporter: Jason <dravet>
Component: gnome-appletsAssignee: Ray Strode [halfline] <rstrode>
Status: CLOSED DEFERRED QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhide   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-03-30 18:05:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jason 2006-09-30 16:02:36 UTC
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 23:10:36 UTC
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 18:05:15 UTC
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.