+++ This bug was initially created as a clone of Bug #906854 +++ [snip discussion of the original bug] --- Additional comment from Patrick O'Callaghan on 2013-02-02 00:04:46 EST --- (In reply to comment #11) > Can you please test: > http://koji.fedoraproject.org/koji/taskinfo?taskID=4923179 > ? Nearly but not quite. The changes now execute without error (checked by running 'date' from a Shell while the dialogue is still open), but when I exit the dialoque it asks if I want to Apply or Discard the change. Hitting Apply causes the change to revert to UTC. I didn't check what Discard does. --- Additional comment from Kevin Kofler on 2013-02-02 00:51:22 EST --- Hmmm, can you please check what time zone is selected in the dialog after you select your timezone and click Apply, but before you exit the dialog? I suspect it is jumping back to UTC, which in turn makes it ask you whether to apply or discard the change which reverts the timezone to UTC (i.e. Discard is actually what you want then). If I'm right and that's what happening, then the problem must be when the dialog reloads the time information using Dtime::load(). That function uses KSystemTimeZones::local() to determine the current time zone, somehow that must be returning wrong or outdated information. --- Additional comment from Kevin Kofler on 2013-02-02 01:03:23 EST --- This is another bug, in ktimezoned: https://projects.kde.org/projects/kde/kde-runtime/repository/revisions/master/entry/ktimezoned/ktimezoned.cpp#L337 It will only watch for changes to /etc/localtime if the file already existed. So if the file was not there and it gets created, nothing happens.
I have a possible fix for that too, but I need some sleep now, I'll do builds after sleeping.
From bug #906854: Patrick O'Callaghan 2013-02-02 09:29:48 EST > Hmmm, can you please check what time zone is selected in the dialog after > you select your timezone and click Apply, but before you exit the dialog? I > suspect it is jumping back to UTC, which in turn makes it ask you whether to > apply or discard the change which reverts the timezone to UTC (i.e. Discard > is actually what you want then). > > If I'm right and that's what happening, then the problem must be when the > dialog reloads the time information using Dtime::load(). That function uses > KSystemTimeZones::local() to determine the current time zone, somehow that > must be returning wrong or outdated information. Well spotted, that's exactly what is happening. After selecting the new timezone the dialogue box whites out and when it comes back I find UTC is still selected, even though 'date' shows the new timezone.
Can you please test this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=381928 ? (If you're testing on a live image, don't forget to also apply the kde-workspace fix from bug #906854.)
You probably need to restart your session after updating the package, so that the fixed ktimezoned actually gets started.
(In reply to comment #3) > Can you please test this build: > http://koji.fedoraproject.org/koji/buildinfo?buildID=381928 > ? > > (If you're testing on a live image, don't forget to also apply the > kde-workspace fix from bug #906854.) OK, tested and working. The dialogue correctly sets and keeps the new timezone. Thanks Kevin.
Patch sent upstream: https://git.reviewboard.kde.org/r/108727/
There is still a (relatively minor) issue which I hadn't noticed earlier. After applying a timezone change and proceeding to exit the dialogue, you still have to confirm Apply or Discard. Selecting Apply simply exits (leaving the change in place), but Discard does the same thing, i.e. it doesn't revert the change. IIRC in other Settings dialogues hitting Apply before exiting means you don't have to reconfirm, so the question doesn't arise. At the same time, making a change and attempting to exit without hitting Apply will bring up the confirmation dialogue with the expected semantics. IOW the Time/Date is inconsistent with this behaviour.
kde-runtime-4.9.5-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/kde-runtime-4.9.5-2.fc18
Package kde-runtime-4.9.5-2.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing kde-runtime-4.9.5-2.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1932/kde-runtime-4.9.5-2.fc18 then log in and leave karma (feedback).
(In reply to comment #7) > There is still a (relatively minor) issue which I hadn't noticed earlier. > After applying a timezone change and proceeding to exit the dialogue, you > still have to confirm Apply or Discard. Selecting Apply simply exits > (leaving the change in place), but Discard does the same thing, i.e. it > doesn't revert the change. IIRC in other Settings dialogues hitting Apply > before exiting means you don't have to reconfirm, so the question doesn't > arise. At the same time, making a change and attempting to exit without > hitting Apply will bring up the confirmation dialogue with the expected > semantics. IOW the Time/Date is inconsistent with this behaviour. These comments still apply as of 4.9.5-7 (F18). IMHO the easiest fix is to disable the confirmation when the user has already hit Apply in the settings dialogue. This would be consistent with other settings dialogues.
kde-runtime-4.9.5-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.