PC hardware time changed during Puppy boot

[greengeek]

Sometimes when I am trialling puppies (new or old releases) I discover that my PC (bios?) time changes some time during the boot process and the incorrect time carries over into any pup i test from that point on - including when i boot back into my "daily driver" pup which is personalised and always has the same timezone set.

On a side note i read recently that "Linux relies on the PC hardware time being set correctly".

So two questions;

1) Does Linux need the hardware clock to be correct? Can't an incorrect hardware clock be compensated for by changing the software time or timezone?

2) Is it normal for a Puppy to be able to change the hardware clock during boot? (I don't know if every pup i test is doing this, or if only some are doing it). Maybe this is only happening if i accidentally select an unusual timezone during the Quicksetup routine? (probably occurs on pups where the tap-to-click is pre-enabled during boot and my fingers trigger the tap function accidentally at an unknown time)

[bigpup]

What is the computer?
Has the cmos battery been changed?

If the CMOS battery in your computer or laptop dies, the machine will be unable to remember its hardware settings when it is powered up. It is likely to cause problems with the day-to-day use of your system. The CMOS battery maintains computer settings

.
A weak battery can also cause computer hardware clock issues.

Well, the hardware clock could also be going bad, but changing the cmos battery, usually fixes strange bios problems.

[smokey01]

@greengeek I always set my hardware clock to my local time. I then set the timezone. Sometimes when I test a new distro the clock in the panel is wrong until I set the locale and or timezone. Different distros have different default timezones set. If I make a save file of the new distro and reboot the time is correct both in the panel clock and hardware. When I boot back into my original distro all is correct as well. I have not experienced the hardware clock changing between distros. Seems a little odd unless of course your CMOS battery is stuffed as already mentioned.

[wiak]

@greengeek I always set my hardware clock to my local time. I then set the timezone. Sometimes when I test a new distro the clock in the panel is wrong until I set the locale and or timezone.

I also consider this the best approach. But yes it is possible for a running operating system to change the hardware clock via related command, however, I do find I can avoid and/or fix most issues by always setting the hardware clock to local time and using timezone setup to keep things correct. I prefer doing that to simply relying on auto-NTP servers to fix things regardless. If you have timezone wrong and ntp running it could be that the OS will keep auto-changing system hardware time in order to 'fix' things and it can be tricky getting out of that annoying loop. I suggest turn off ntp when booted, fix timezone and then reboot and immediately correct hardware clock to localtime (in e.g. BIOS) prior to finally letting system boot up. All should be fine in the end, but there are commands you can run to fix it all up again anyway. Here is a note I once wrote when I was using a XenialDog system (may or may not work when using Puppy):

BEGIN
During Boot, set your RTC (BIOS) clock to your actual local time.
Boot into XenialDog and set your timezone (e.g. using XenialStartMenu -> Settings -> Set TimeZone).
Then open a terminal and run the command:

Code:

Code: Select all

timedatectl set-local-rtc 1 --adjust-system-clock

Finally, save your new settings with save2flash or similar.
For further info (e.g. to instead change Windows to use UTC...) see here:
http://ubuntuhandbook.org/index.php/201 ... indows-10/
END - All should now be fine...

wiak

[greengeek]

What is the computer? Has the cmos battery been changed?

It is a Toshiba M700 laptop - approx 12 years old and must still be on it's original cmos battery.

If the CMOS battery in your computer or laptop dies, the machine will be unable to remember its hardware settings when it is powered up. It is likely to cause problems with the day-to-day use of your system. The CMOS battery maintains computer settings. A weak battery can also cause computer hardware clock issues.

The system seems to remember it's settings and time fine so i think there is still life in the battery. The rtc setting only seems to change when i am testing alternative puppies from time to time.

@greengeek I always set my hardware clock to my local time. I then set the timezone. Sometimes when I test a new distro the clock in the panel is wrong until I set the locale and or timezone. Different distros have different default timezones set.

I just retested a bunch of pups - as i had it in my mind that one of them must have been responsible for having changed the hardware clock - but so far they all seem to behave the same way:

- after boot they display the current hardware clock time in the tray clock area - but after i change the timezone in the Quicksetup dialog i see the tray clock momentarily flash the new time for one second - but then the display reverts back to the hardware clock time. (although if I hover over the tray clock it will tell me what the new timezone is).

So i guess this means that the puppy timezone is more or less irrelevant.

It seems that in order to change the hardware clock via software it must be done from the puppy date/time alteration utility so i guess I must have done that at some point in my testing without realising it.

I am still confused about what parameters are taken into account when a browser tells you that the system time is out of range and pages cannot be served - is this because of hware clock, sware clock or timezone? (or a combo?)

I do find I can avoid and/or fix most issues by always setting the hardware clock to local time and using timezone setup to keep things correct. I prefer doing that to simply relying on auto-NTP servers to fix things regardless.

.. there are commands you can run to fix it all up again anyway. Here is a note I once wrote when I was using a XenialDog system (may or may not work when using Puppy)...

Thanks for the notes - unfortunatey timedatectl utility is not in my pup but i guess the puppy menu based utility must be doing the same thing.

At least i have learned that my reliance on timezone is misplaced. Maybe this is because I never have a savefile so that must mean that my rtc setting is the key. I must have used the menu to change the time myself without realising.

[bigpup]

What happens if, along with changing the time zone, you also check, change, select the date and time?
Use set date and time.
Even if it is showing correct date and time.
Use this program to apply the correct setting.

But, if you use no save.
This is not going to help between boots.
The set date and time settings are not saved.

[greengeek]

What happens if, along with changing the time zone, you also check, change, select the date and time?
Use set date and time.
Even if it is showing correct date and time.
Use this program to apply the correct setting.

The PC rtc clock time definitely changes permanently if I do this. It seems timezone changes do not alter the rtc clock but the time/date utility does.

But, if you use no save.
This is not going to help between boots.
The set date and time settings are not saved.

True. Any change via that date/time utility will be lost at shutdown - at least as far as software is concerned - but any change the date/time utility made WILL have changed the rtc. My puppy is personalised (via sfs rather than pupsave) and knows it's timezone - but i guess relies on rtc being correct.

I feel that some puppies MAY be changing the date/time by themselves as part of the Quicksetup defaults.

I have not yet identified which of my trial puppies triggered this most recently - but I have found an interesting variation when booting Precise Light 572:

The Quicksetup screen has "Canada Yukon" timezone as default but more importantly has "Hardware clock uses UTC" ticked. This is different to the last few pups i have been testing. Interestingly while the Quicksetup screen was displayed (waiting for me to review settings) my tray clock displayed Yukon time. I thought it had already modified my rtc value but no in fact it had not - it was only fooling me by temporarily displaying the wrong time.

This particular clock display behaviour seems different to the other pups so i will test further. Also seems odd that "UTC" was selected - almost as if this pup carries some residue of jrb's personal setup rather than generic settings.

[greengeek]

Then open a terminal and run the command:

Code: Select all

timedatectl set-local-rtc 1 --adjust-system-clock

In my Slacko 5.6 based puppy /usr/sbin/set-time-for-puppy seems to use the following syntax to change rtc clock:

Code: Select all

hwclock --systohc --${HWCLOCKTIME} 

(If i am understanding correctly...)

[garnet]

Windows defaults to storing local time in the hardware clock.
Unix defaults to storing UTC time in the hardware clock.
Pups' defaults vary.

1) Does Linux need the hardware clock to be correct?

If you have internet connection: No. You can use ntpd to pull time from the atomic clocks available in the internet.
If you don't have internet connection: Yes, otherwise you will have to manually set/correct time every time you boot.

Is it normal for a Puppy to be able to change the hardware clock during boot?

No. The time changes only if you change it yourself.

[Sky Aisling]

Thank you @greengeek for starting this thread.

I've noticed when posting in this forum and other venues that the time shown that I made the posts is not always the same as my local time shown in JWM tray when I did the post.

Do I have the settings correct?

Puppy is Dpup Stretch 4.9.101 (i686)

[6502coder]

@Sky
All times shown on the Forum are UTC time, regardless of what your local time may be.
If you think about it, it would be hopelessly confusing if all posts were stamped with their local time!

[tosim]

IF you are in the LA,Southern Cal area, then YES, your settings are correct.

[williams2]

Puppy should not change the hardware clock unless you actually run a program designed to change the hardware clock time.

I set the HC about a year ago, and have been tweaking the drift setting in /etc/adjtime to set the system time using the drift correction accurate to within a few thousands of a second. (After a year, my hardware clock is about 6 minutes fast.)
I keep a copy of the adjtime on my hard drive and copy it to /etc/ in whatever version of Puppy I am running at the moment.

A couple of weeks ago, I booted Fatdog 8.10, and just setting the timezone in the initial configuration seemed to have changed the hardware clock time. So I had to reset the HC.

Some Linix operating systems set the hardware clock from the system clock everytime the system shuts down (reboot or poweroff).
This can cause the hardware clock setting to drift a little more than it would if it was left alone, and to be a little less accurate.
But it would correct the HC for drift, so MS Windows would read the correct time.
I don't think any Puppy sets the HC when it shuts down.

[bigpup]

What is the computer? Has the cmos battery been changed?

It is a Toshiba M700 laptop - approx 12 years old and must still be on it's original cmos battery.

So, how many years do you think a cmos battery should last?

You can expect the CMOS battery to last for up to five years. The more your computer is used (powered up), the longer the battery will last.

What do you think is going to not work if you put a new, fully powered, fully new working internal connections, cmos battery in the computer??

I guess I am the only person, in the world, that has fixed a battery powered clock (that did not keep correct time) by changing the battery

[greengeek]

I guess I am the only person, in the world, that has fixed a battery powered clock (that did not keep correct time) by changing the battery

No, i definitely have some other laptops (eg Toshiba TE2100) that have major problems with the RTC battery and that causes all sorts of timekeeping issues just like you are describing.

But this particular M700 laptop has had no problems remembering the time - the issue i am having is just that some puppies change the time display in the system tray during boot.

It seems that the change in displayed time is in most cases only temporary - the time returns to normal after quicksetup finishes - as long as the RTC time was correct before booting the new puppy.

I still feel that one of the puppies i booted actually DID change the RTC time permanently during boot (maybe it was Fatdog as williams2 reported above...) - but i tried so many pups i am now a little confused what triggered my problem.

Let me try to clarify where i got to:
- My RTC battery is still good (even after all this time - so probably a silver RTC battery rather than lithium...). The system always remembers the RTC time correctly.
- The RTC time can be changed manually and will be remembered correctly.
- Some puppies - when booted without savefile - bring up the Quicksetup screen and display a different time in the system tray - as if the RTC time was incorrect !!! - but after the Quicksetup screen finishes the time returns to displaying the correct RTC time.
So the "time" problem in these cases was a bogus "displayed time" issue rather than an actual loss of RTC time

But at least once - the RTC time did change. Either some puppy or other DID change the RTC time - or else i accidentally did it myself.

I am definitely sure that the puppies i was booting were not all handling the time display the same way - that is why i am still a little confused.

I will come back to this issue when i have finished sorting out the scripts that can be used to set the following items:
- Manual set of RTC time (from software script rather than BIOS control)
- Manual set of Timezone
- Manual set of locale.

I still don't have those matters clear in my head yet.

[greengeek]

Actually - thanks Bigpup - you have prompted me to find out more about my M700 RTC and i found a stripdown guide that shows where the RTC battery is:

http://www.irisvista.com/tech/laptops/T ... bly-16.jpg

It definitely looks as if standard coin batteries are in use so i guess i have been lucky so far. Probably will fail next weekend!

.

tablet-pc-disassembly-16.jpg (72.4 KiB) Viewed 475 times

.

[jamesbond]

This is because most puppies choose to keep the hardware clock (hwclock aka RTC) in local time.
This is a __VERY__ bad practice inherited from Windows days (which it inherited from MS-DOS, and MS-DOS always stored hwclock in local time because ... well just don't get me started).

Unix systems, on the other hand, traditionally always keep hwclock in UTC.

It only makes sense to keep hwclock in local time if you're dual-booting with Windows.
If you don't dual boot Windows, there is no reason whatsoever to stick with the bad practice.

---

An example of bad things that could happen when you set hwclock to localtime: each time you change your timezone, your hwclock will be changed to. It has to, because changing timezone changes the localtime, and since the hwclock is stored in localtime, it has to be changed too (otherwise next time you boot, your hwclock will operate in a different timezone than your OS, and the result would be screwy).

If hwclock is stored in UTC all these acrobatics is not necessary. You can change timezone ten times a day and the hwclock won't be touched. And oh DST works automatically too.

---

Hence Fatdog by default stores hwclock in UTC. That's what it uses if you boot it without savefile. And the time will look wrong. If you try to adjust the time, then hwclock will be updated; and next time you boot puppy that assumes hwclock in localtime, the time will look wrong again.

The proper way to do it, if you insist on running hwclock in localtime, is to run Fatdog QuickSetup (or just open the Control panel -> System -> Configure hw clock) and set it "local time". After that, you can set your timezone and your time; and make sure you have a savefile. On next boot, all will be all right again with the world.

[baldronicus]

Hi @greengeek et all. Greengeek, would you recall if the time differential that you noticed would have been 12 hours?
The reason for asking is that Wellington is UTC +12. I am not sure how it really works, or the finer points of it, but I think that time around the globe might be divided into hourly (maybe half-hourly or whatever) bands. Hopefully all of NZ would be in the one band (as you sort of stretch down, whilst here in Oz we, sort of, stretch across as well (hence multiple time zones)). I can't remember which is latitude and which is longitude. Good thing I'm not a sailor!
If the hardware clock was set back by 12 hours then it would be likely that a UTC adjustment has been made.
Whilst Puppies might default to using local time (possibly, as Jamesbond suggests, to work in better with earlier Windows environments (I don't know if later Windows stuff might use UTC, or not)), it is possible for at least some Puppies that the system might initially be loading with the developer's local [EDIT (time) should be] timezone (possibly on a UTC basis). Which might explain the initial time differential before you change to your local settings.
The above is just a guess, of course.
Although many/most/all Puppies might default to local time, most of the Quick Setup Dialogs that I have seen have a "Hardware clock set to UTC" checkbox under the drop-down list for the timezone.
If the difference is 12 hours, you are not running Windows, and the differential remains a concern, then maybe there might be an argument for moving to UTC for greater consistency, since you just have to click on the check box when testing various Puppies.
However that would mean setting your hardware clock back 12 hours (if you have already corrected it) and then modifying the .sfs for your main load (unless, of course, you are actually already running on a UTC basis). I don't know which way you would want to approach it.
Apologies if it is not the problem and I have been wasting your time.
Thanks.

[bigpup]

Some puppies - when booted without savefile - bring up the Quicksetup screen and display a different time in the system tray - as if the RTC time was incorrect !!! - but after the Quicksetup screen finishes the time returns to displaying the correct RTC time.

That is kind of normal operation with very first time booting.
That is why Quicksetup has settings for time issues.
This has never been issue free in the past, but is getting better with newer Puppy versions built with the newest Woof-CE.

[greengeek]

Hi @greengeek et all. Greengeek, would you recall if the time differential that you noticed would have been 12 hours?

Hi baldronicus - i had the time issues while i was testing quite a few pups and as far as i recall most of the time the differential in the displayed time (system tray) was less than 12 hours.

It seemed that most of the puppies defaulted to their "devs" home area which from memory was either Los Angeles, Perth or sydney - with the exception of jrb's pups which default to Canada time.

If the hardware clock was set back by 12 hours then it would be likely that a UTC adjustment has been made.

I wish i could remember exactly what the time shift was during the occasion where the hardware clock did actually get permanently changed. I don't think it was 12 hours.

Although many/most/all Puppies might default to local time, most of the Quick Setup Dialogs that I have seen have a "Hardware clock set to UTC" checkbox under the drop-down list for the timezone.

Yes i have spotted that but i don't think i ever (intentionally) checked that box - as i did not understand what UTC was.

there might be an argument for moving to UTC for greater consistency, since you just have to click on the check box when testing various Puppies. However that would mean setting your hardware clock back 12 hours

Yep, i think i will give that a go and see what further testing reveals... Seems to be what jamesbond recommends so it's worth a go.