Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The local time is shifted when changing the timezone. After pressing OK, the local time is different from what was displayed in the GUI. Version-Release number of selected component (if applicable): Tested with 1.9.36-1-fc10 (but source code of 1.9.38-1.fc11 looks just as bad) How reproducible: Always Steps to Reproduce: 1. Start system-config-date 2. Check the Date&Time tab (do not change it). 3. Modify the timezone (to a different zone). Press OK. 4. Realize that the local time has just changed under your feet. Actual results: After pressing OK, the local time is set to the different value than displayed in the GUI. Expected results: Local time displayed should be set to the value seen in the GUI. Additional info: I think the problem is that the system keeps UTC constant when changing the timezone + the timezone is changed AFTER setting the time. See tentative fix attached. Note: UTC is an internal implementation detail not even displayed in the GUI. The end-user does not see and does not care about UTC.
Created attachment 343557 [details] tentative fix: set timezone before setting local time
Created attachment 345342 [details] patch version 2 The previous patch is not enough, it fixes only the NTP-disabled case, leaving the NTP-enabled case with the very same bug. This new patch fixes both cases.
Sorry for the late reply, I've just returned from vacation. While I see your issue, this is not a bug: If you change the time zone, the local time gets changed because local time is different in different time zones. I think we are dealing with two different use cases here (ignoring whether the hardware clock is set to UTC or local time, only for the non-NTP case): - I assume the local time is set correctly for the old time zone, and should be changed for the new time zone. Think of taking your laptop on travel into a different time zone (which I just did). - You assume the local time is wrong with regard to the old time zone, only correct with regard to the new one. With regard to NTP, you assumptions would be wrong IMO: the job of NTP is to keep the local time set correctly, so it needs to be changed with the time zone if it should continue to be correct. I'm not sure how to cater to your use case additionally and keep the interface sane, e.g. I don't want to ask for the user's intentions every time the time zone is changed. Do you have an idea how to do this cleanly UI-wise?
(In reply to comment #3) > Sorry for the late reply, I've just returned from vacation. I am glad to see that you are testing this bug very seriously! > While I see your issue, this is not a bug: If you change the time zone, the > local time gets changed because local time is different in different time > zones. > I think we are dealing with two different use cases here (ignoring > whether the hardware clock is set to UTC or local time, only for the non-NTP > case): > > - I assume the local time is set correctly for the old time zone, and should be > changed for the new time zone. Think of taking your laptop on travel into a > different time zone (which I just did). Simple things first: as you suggested let us put NTP aside for the moment. Even with the NTP cases out of the picture, I think you are restricting the use of the timezone tab to only one specific "traveler" scenario: traveling to a different timezone while the UTC stays correct. You are basically assuming that, if the user is going to fix the timezone in the timezone tab, then he is not even going to look at the value local time tab. But the applet is offering all three panels *at the same time* (this could be the root problem), so the applet looks much more ambitious and flexible than that. You do not know what the user will do with the applet. The user can perfectly use BOTH the local time tab and the timezone tab because he wants to fix both, in any order. In which case his entry in the local time tab is systematically corrupted. Bad: never ignore user input. > - You assume the local time is wrong with regard to the old time zone, only > correct with regard to the new one. I am trying not to assume any specific scenario. I am assuming that *everything is wrong* and that the user is possibly going to fix everything (local time and timezone) in any order. If the applet is designed to handle the general case well, then all other particular cases should just work as well. If you think this is not realistic please consider configuring new machines just shipped from some random place in the world, motherboards running out of batteries, live CDs images meant to be run anywhere in the world, etc. Even in the restricted "traveler" scenario you will shoot yourself in the foot with the current applet if you dual boots with Windows, since Windows (stupidly) requires you to maintain the system clock in local time. After landing to a new timezone, suppose you first fix the time in Windows, thereby changing the system clock. As soon as you reboot to Linux everything is now wrong and you have put yourself outside of the comfy, restricted traveler scenario above. > With regard to NTP, you assumptions would be wrong IMO: the job of NTP is to > keep the local time set correctly, so it needs to be changed with the time zone > if it should continue to be correct. Sorry you lost me here (but I am pretty sure NTP safely ignores timezone madnesses and does everything in UTC). > I'm not sure how to cater to your use case additionally and keep the interface > sane, e.g. I don't want to ask for the user's intentions every time the time > zone is changed. Do you have an idea how to do this cleanly UI-wise? A simple solution could be to constraint the user to configure things _in sequence_. Do not display tabs concurrently, this is what makes everything more complicated. First ask for the timezone. Once the user has configured it, apply whichever guess you want to UTC / local time. Preserve one or the other, your choice, BUT THEN throw the (possibly changed) local time into the user's face and ask for confirmation. This might not be the best UI ever but it sounds very safe to me. The best concurrency is no concurrency. I am not yet sure how NTP would fit in this. What I do not like with the current interface is that it prevents me to enable NTP AND fix the initial clock value. If the clock is initially wrong AND I want NTP enabled on the box, then I have to wait for 5 minutes for the clock to be fixed; I can not immediately fix by myself.
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Reopened. I'm undecided about this: I don't want to force a wizard style workflow on the user, but I also would appreciate if how s-c-date operates in this regard is more transparent to the user. I'll set this to FutureFeature so it doesn't get auto-closed again.
> > Sorry for the late reply, I've just returned from vacation. > > I am glad to see that you are testing this bug very seriously! Sorry for being cryptic, I meant: "... by actually travelling to different timezones."
(In reply to comment #8) > Sorry for being cryptic, I meant: "... by actually travelling to different > timezones." Heh, that was coincidental ;-).
Created attachment 439717 [details] Implements a (single) --page option in just 3 lines (In reply to comment #7) > I'm undecided about this: I don't want to force a wizard style workflow on the > user,... Well, after some hair loss, I came to the conclusion that a sequential workflow is the only sane way to deal with my use case. So I have a shell script that goes like this: system-config-date --page=1 # set timezone and utc flag system-config-date --page=0 # set datetime This required a few minor modifications to system-config-date, the first and non-intrusive one being attached right now.
Thanks for taking the time to submit this bug. Unfortunately, I haven't gotten around to fix this issue, sorry for that. Because I don't actively develop system-config-date anymore, I won't likely find the time to work on this ticket, so I'll close it now.