Bug 205861

Summary: Clock settings tool assumes hardware clock is UTC
Product: [Applications] systemsettings Reporter: Patrick O'Callaghan <pocallaghan>
Component: kcm_clockAssignee: Paul Campbell <paul>
Status: RESOLVED FIXED    
Severity: normal CC: jpwhiting, justin.zobel, kde, nihili
Priority: NOR Flags: jpwhiting: gardening+
Version: unspecified   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Patrick O'Callaghan 2009-09-01 05:56:33 UTC 
Version:            (using KDE 4.3.0)
OS:                Linux
Installed from:    Fedora RPMs

On dual-booted machines, one system might assume that the hardware clock is set to UTC, and the other might assume it isn't. This leads to inconsistent clock settings when switching between the two systems. For example Windows normally assumes the hardware clock is local time and Linux usually assumes the opposite. The Gnome clock setting widget (also accessible via system-config-clock) has a tick-box to select which of these alternatives to use, but the KDE Date and Time settings dialogue does not. This means that the KDE user has to use the Gnome tool to set the option, even assuming he knows how to do this. This situation is undesirable and should be changed.
Comment 1 nihili 2014-09-16 23:22:37 UTC 
more in my case. Kubuntu kde 4.13...
On changing the time , on the confirming i get an autentification error message
Comment 2 David Edmundson 2015-02-05 20:24:55 UTC 
Once we make the timedated change it'll be possible to do this with
SetLocalRTC()

whether we want to clutter the UI with a windows hack is a different question.
Comment 3 Jeremy Whiting 2015-09-10 00:02:05 UTC 
I wouldn't consider adding a checkbox to be a windows hack, but a way of working well on systems where dual boot is set up.

Also marking this as gardening+ as it should be relatively quick to solve/close.
Comment 4 Justin Zobel 2020-10-25 11:26:31 UTC 
This isn't a feature at this time still, if it could be implemented easily I think it would help a small but grateful group of users out.
Comment 5 David Edmundson 2024-09-16 17:40:13 UTC 
We now use timedatectl which takes care of this