The comment about clock_hctosys in /etc/conf.d/hwclock says you do not need to set it to "YES" if you are running a modern kernel with CONFIG_RTC_HCTOSYS set to y. This is misleading if the hardware clock is set to local time as the kernel CONFIG_RTC_HCTOSYS option assumes the hardware clock is set to UTC. It would be less misleading if the sentence read as follows: # You do not need this if you are running a modern kernel with CONFIG_RTC_HCTOSYS set to y AND your Hardware Clock is set to UTC. Reproducible: Always
I looked at the documentation in make menuconfig for the CONFIG_RTC_HCTOSYS option, but I do not see any statement there about the kernel assuming any particular timezone setting for the RTC. Where are you getting the idea that the kernel expects UTC? Thanks, William
(In reply to comment #1) > Where are you getting the idea that the kernel expects UTC? Because timezones are a user-space thing that the kernel knows nothing about. There is no kernel configuration option or kernel command-line parameter to tell the kernel what the RTC offset from UTC is (and for good reason!).
Also, see the description of CONFIG_RTC_HCTOSYS_DEVICE which says the device should record time in UTC. If the RTC is set to local time, the kernel's system time will be wrong until the hwclock init script sets it. I wonder what happens when resuming from suspend-to-disk? Does the hwclock script get run after resume, or will the system time remain wrong in that case? Now I'm worried!
(In reply to comment #3) > Also, see the description of CONFIG_RTC_HCTOSYS_DEVICE which says the device > should record time in UTC. This is what I needed to see. I'm wondering if we should also assume clock="UTC" if clock_hctosys="YES"? > If the RTC is set to local time, the kernel's system time will be wrong until > the hwclock init script sets it. I wonder what happens when resuming from > suspend-to-disk? Does the hwclock script get run after resume, or will the > system time remain wrong in that case? Now I'm worried! I can't really answer that, but if there is an issue with suspend/resume I'm not sure this bug is the place for it since we are just dealing with the hwclock script.
(In reply to comment #4) > (In reply to comment #3) > > Also, see the description of CONFIG_RTC_HCTOSYS_DEVICE which says the device > > should record time in UTC. > > This is what I needed to see. I'm wondering if we should also assume > clock="UTC" if clock_hctosys="YES"? No, because on a Windows dual-boot system you'd want to set clock="local" and clock_hctosys="YES". Windows traditionally assumes the hardware clock is local time. Although some versions of Windows have registry hacks to allow the hardware clock to be set to UTC, these hacks don't work properly on all versions of Windows. > > If the RTC is set to local time, the kernel's system time will be wrong until > > the hwclock init script sets it. I wonder what happens when resuming from > > suspend-to-disk? Does the hwclock script get run after resume, or will the > > system time remain wrong in that case? Now I'm worried! > > I can't really answer that, but if there is an issue with suspend/resume I'm > not sure this bug is the place for it since we are just dealing with the > hwclock script. Agreed, it's unrelated. I just thought I'd mention it in passing!
(In reply to comment #5) > (In reply to comment #4) > > I can't really answer that, but if there is an issue with suspend/resume I'm > > not sure this bug is the place for it since we are just dealing with the > > hwclock script. > > Agreed, it's unrelated. I just thought I'd mention it in passing! Although I do think it would be useful if the /etc/init.d/hwclock script had a "restore()" action as it already has a "save()" action. These actions could be usefully called during suspend/resume.
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > I can't really answer that, but if there is an issue with suspend/resume I'm > > > not sure this bug is the place for it since we are just dealing with the > > > hwclock script. > > > > Agreed, it's unrelated. I just thought I'd mention it in passing! > > Although I do think it would be useful if the /etc/init.d/hwclock script had a > "restore()" action as it already has a "save()" action. These actions could be > usefully called during suspend/resume. Possibly, but that is still another bug. :-)
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Also, see the description of CONFIG_RTC_HCTOSYS_DEVICE which says the device > > > should record time in UTC. > > > > This is what I needed to see. I'm wondering if we should also assume > > clock="UTC" if clock_hctosys="YES"? > > No, because on a Windows dual-boot system you'd want to set clock="local" and > clock_hctosys="YES". Windows traditionally assumes the hardware clock is local > time. Although some versions of Windows have registry hacks to allow the > hardware clock to be set to UTC, these hacks don't work properly on all > versions of Windows. Based on the requirement you pointed out above regarding CONFIG_RTC_SYSTOHC_DEVICE being set to UTC, I would recommend using clock_systohc="NO" in this situation. clock="local" and clock_systohc="yes" seem to be mutually exclusive to me. What am I missing?
(In reply to comment #8) > Based on the requirement you pointed out above regarding > CONFIG_RTC_SYSTOHC_DEVICE being set to UTC, I would recommend using > clock_systohc="NO" in this situation. clock="local" and clock_systohc="yes" > seem to be mutually exclusive to me. > > What am I missing? I assume you meant CONFIG_RTC_HCTOSYS_DEVICE and clock_hctosys in the above. Setting clock="local" and clock_hctosys="YES" tells /etc/init.d/hwclock to set the system time using the local time stored in the hardware clock. System time is always assumed to be UTC even if it has been set incorrectly. If you have CONFIG_RTC_HCTOSYS configured in the kernel as well, it would read the hardware clock and set the system clock to the same time assuming it is UTC. If the hardware clock is actually set to local time, the system time will be wrong by the difference between local time and UTC. When hwclock init script is started with the config parameters clock="local", clock_hctosys="YES" it will run the binary /sbin/hwclock as follows: hwclock --hctosys --localtime This will read the hardware clock, convert it from local time to UTC, and set the system time. The result is that the system time will be set to roughly the correct time, depending on how accurately the hardware clock was set to local time in the first place. Of course there are well known problems with setting the hardware clock to local time involving ambiguities around DST transitions which may require the time to be adjusted by an hour manually twice a year, but that's the price you pay for Windows compatibility!
(In reply to comment #9) > Setting clock="local" and clock_hctosys="YES" tells /etc/init.d/hwclock to > set the system time using the local time stored in the hardware clock. > System time is always assumed to be UTC even if it has been set incorrectly. > > If you have CONFIG_RTC_HCTOSYS configured in the kernel as well, it would > read the hardware clock and set the system clock to the same time assuming > it is UTC. If the hardware clock is actually set to local time, the system > time will be wrong by the difference between local time and UTC. > > When hwclock init script is started with the config parameters > clock="local", clock_hctosys="YES" it will run the binary /sbin/hwclock as > follows: > > hwclock --hctosys --localtime > > This will read the hardware clock, convert it from local time to UTC, and > set the system time. The result is that the system time will be set to > roughly the correct time, depending on how accurately the hardware clock was > set to local time in the first place. Ah, so what we have is if CONFIG_RTC_HCTOSYS=y is set in the kernel, clock_hctosys should be "no", correct? If that is the case, would it make more sense to change the hwclock script so that clock_hctosys should have the same setting as CONFIG_RTC_HCTOSYS?
(In reply to comment #10) > Ah, so what we have is if CONFIG_RTC_HCTOSYS=y is set in the kernel, > clock_hctosys should be "no", correct? If CONFIG_RTC_HCTOSYS=y and the RTC device is set to local time, the kernel will at least initialize the system time to within a few hours of what it should be (the difference between UTC and local time). That's going to be closer to real time than whatever default initial system time the kernel would otherwise set. So there is some benefit in having both CONFIG_RTC_HCTOSYS=y and clock_hctosys=y > If that is the case, would it make more sense to change the hwclock script > so that clock_hctosys should have the same setting as CONFIG_RTC_HCTOSYS? I'd rather they were independent for the reason given above. Besides, the hwclock script might not be able to determine the CONFIG_RTC_HCTOSYS setting of the running kernel.
How do you feel about the following change to /etc/conf.d/hwclock? I think this makes it a bit more clear what the hwclock script is doing. diff --git a/conf.d/hwclock b/conf.d/hwclock index 230d81d..78ee7fa 100644 --- a/conf.d/hwclock +++ b/conf.d/hwclock @@ -4,9 +4,11 @@ # you should set it to "local". clock="UTC" -# If you want to set the system time to the current hardware clock -# during bootup, then say "YES" here. You do not need this if you are -# running a modern kernel with CONFIG_RTC_HCTOSYS set to y. +# If you want the hwclock script to set the system time (software clock) +# to match the current hardware clock during bootup, leave this +# commented out. +# You should set this to "NO", however, if you are running a modern +# kernel with CONFIG_RTC_HCTOSYS set to y. #clock_hctosys="YES" # If you do not want to set the hardware clock to the current system
(In reply to comment #12) > How do you feel about the following change to /etc/conf.d/hwclock? > I think this makes it a bit more clear what the hwclock script is doing. > > +# You should set this to "NO", however, if you are running a modern > +# kernel with CONFIG_RTC_HCTOSYS set to y. I would change that last sentence to: # You should set this to "NO", however, if you are running a modern # kernel with CONFIG_RTC_HCTOSYS set to y and your hardware clock is # set to UTC. because you'd always want clock_hctosys set to "YES" (the default) if your hardware clock is set to local time.
(In reply to comment #13) > (In reply to comment #12) > > How do you feel about the following change to /etc/conf.d/hwclock? > > I think this makes it a bit more clear what the hwclock script is doing. > > > > +# You should set this to "NO", however, if you are running a modern > > +# kernel with CONFIG_RTC_HCTOSYS set to y. > > I would change that last sentence to: > > # You should set this to "NO", however, if you are running a modern > # kernel with CONFIG_RTC_HCTOSYS set to y and your hardware clock is > # set to UTC. > > because you'd always want clock_hctosys set to "YES" (the default) if your > hardware clock is set to local time. In other words, the following is invalid in /etc/conf.d/hwclock: clock="local" clock_hctosys="no" Correct?
(In reply to comment #14) > (In reply to comment #13) > > because you'd always want clock_hctosys set to "YES" (the default) if your > > hardware clock is set to local time. > > In other words, the following is invalid in /etc/conf.d/hwclock: > > clock="local" > clock_hctosys="no" > > Correct? Unwise, but maybe some crazy person has some reason to do that!
This is fixed in commit 0fa164d.
