BIOS time and Puppy time (ANSWERED)

[Mercedes350se]

Is there a reason that Puppy 3.01 does not automatically adopt BIOS time? Is it a Linux trait in general?

The reason I ask is that, when doing a e2fsck check, I have received a "Superblock write in the future" message. Easy enough to fix, just correct Puppy time.

[Béèm]

Did you enter the correct timezone?

[Mercedes350se]

Did you enter the correct timezone?

Yes, hence my reference to "Easy enough to fix, just correct Puppy time."

That does not answer my original question, "Why doesn't Puppy 3.01 automatically adopt BIOS time rather than leaving it up to the user to select the correct time zone?"

[nooby]

I only wild guess. Barry had some purpose with setting it up like that or him had simply made some mistake and it got corrected later?

AFAIK at least for me the error was also there in later Puppy 4.00 or even in 4.3.1 or even in Quirky? I guess it got corrected in Wary.

I think that a year or two ago Puppy always showed the wrong time. one hour wrong. But sure it could ahve been me doing something odd.

What is it about Puppy 3.01 that make it the best choice for you?

[Mercedes350se]

.. What is it about Puppy 3.01 that make it the best choice for you?

I have become used to the way it operates. I am also of the opinion that why upgrade if the current version does everything that is required.

[Béèm]

Did you enter the correct timezone?

Yes, hence my reference to "Easy enough to fix, just correct Puppy time."

That does not answer my original question, "Why doesn't Puppy 3.01 automatically adopt BIOS time rather than leaving it up to the user to select the correct time zone?"

Nothing in your 2 posts indicates to me that the correct timezone is set. The fact that adjusting the time indicates that the timezone is correct isn't proof to me.

My 3.01 period is long gone now.
I don't remember if I had to readjust the time.
Maybe only when changing to summer time/winter time.

I remember vaguely that going to Windows, that Windows didn't show the correct time. I mostly left it as it was a brief 'visit'. And the time in puppy was still correct.

I am afraid I can't help further.
Also puppy being at 5.x.x I am afraid you won't have a correction for 3.01.

It could be that there have been discussions about this, so maybe with help of the puppy search link in my sig you could find those posts.

[L18L]

Is there a reason that Puppy 3.01 does not automatically adopt BIOS time? Is it a Linux trait in general?

The reason I ask is that, when doing a e2fsck check, I have received a "Superblock write in the future" message. Easy enough to fix, just correct Puppy time.

I think it is puppy time

I am living in time zone GMT+1 (East of Greenwich)
I always enter correct time zone GMT+1

See screenshot taken today some minutes ago
at 16:15 (puppy time: GMT-1)

Easy enough to fix, just correct Puppy time.

If that is so easy, please fix it

And don't forget: forum time is different

[LateAdopter]

I have found that in Lucid Puppy 5.2.5/5.2.8 Puppy time is berserk too.

I am in the UK and my PC clock is set to GMT.

If I set Puppy to: GMT +0 London etc. It shows the same time, but when I reboot the time has become 23 hours slow. i.e. not even the correct day!

I think it must be trying to set +1 hour for summer time but getting wrong.

If I set Puppy to: zulu (which also means GMT) then then it displays the correct time always. By correct I mean the same as the BIOS clock.

The clock setting is needed if any program wants to correct a time from a different zone to local time. e.g for emails or websites, but Puppy should not be changing the locally displayed clock time.

Windows changes the BIOS clock for summer time which can get really confusing when you have more than one operating system installed.

Perhaps Puppy was trying to work around that problem.

[nooby]

Very likely cause of the phenomena here maybe?

Windows changes the BIOS clock for summer time which can get really confusing when you have more than one operating system installed.

I had Windows at that time so maybe it adjusted the Bios clock back from Puppy time something.

It has gone on for years so like Beem point out if you want to solve it do use the search both of us link to the Well minded search.

Others have taken it up now and then.

Are there any way to look at bios time when one are booted? that way one could compare what happens after a boot?

It is an interesting phenomena

[Béèm]

From a certain version of woof on, there is an extra option to tick and use the UTC HW clock.
I never do this and have no problems.
Also I set the timezone to Europe/xxxx (for those being in Europe) and not GMT + or GMT -. It had been proven that this gives problems.

[L18L]

...
I had Windows at that time so maybe it adjusted the Bios clock back from Puppy time something.

I never had windoofs on this box

# pwd
/usr/share/zoneinfo/Etc
#
# cat GMT-1
TZif2GMT-1TZif2GMT-1
<GMT-1>-1
#
# cat GMT+1
TZif2ÿÿñðGMT+1TZif2ÿÿñðGMT+1
<GMT+1>1
#
(color edited by L18L )

might lead to the solution of this mystery

[nooby]

so what could have cause it? I mean if something goes on for years there has to be a reason for it. Maybe he wanted it to be that way

[L18L]

so what could have cause it? I mean if something goes on for years there has to be a reason for it. Maybe he wanted it to be that way

Surely did he (who?) not want it.

But it is time to follow Béèm's advice:

set the timezone to Europe/xxxx

Thank you, Béèm

[nooby]

set the timezone to Europe/xxxx but is that not what one always do?

is there a special entry for Europe? I set it to Bruxelles and Stockholm and Munich and such. is that not what one are supposed to do?

May I ask again. Is there some way to check what the CMOS clock is from within a booted puppy of does one have to shut down and boot into BIOS first and check there?

or can one look at cmos from puppy using terminal cli something?

[disciple]

Hi guys,
If you understand how it works you should be able to set your system up correctly to have no problems with the system time. Most of the pertinent information has been alluded to already, but I'll try to gather it all into one place.

1. Normally when using a real operating system like Linux you set the hardware clock to GMT, and the operating system automatically adjusts what time it displays, according to the selected time zone and any applicable daylight saving / summer time.
2. You would normally select the appropriate named time zone, which will take into account daylight saving / summer time (GMT+## or GMT-## won't take these into account).
3. N.B. that GMT+## and GMT-## settings in fact mean the opposite to what you would expect... but the timezone selector gui in Puppy (or at least in my old version) swaps them around so they do work the way you would expect.
4. Because Microsoft doesn't like to do anything the standard way, Windows sets the hardware clock to your local time, and changes it when you move timezones or for daylight saving / summer time.
5. As Béèm said, it is possible to inform Linux that the hardware clock is set to the local time, for compatibility with Windows. Apparently this is or at least was the default in Puppy, in which case Puppy will be compatible with a dual booted Windows by default, but not with another Linux
Follow the link at http://bkhome.org/blog/?viewDetailed=01616 if you have an old Puppy and want to find out how to switch between the two options.

May I ask again. Is there some way to check what the CMOS clock is from within a booted puppy of does one have to shut down and boot into BIOS first and check there?

I don't know if you can do it with a single command, but you could write a script.
I think `cat /etc/adjtime` will tell you whether Puppy believes the bios clock is in UTC or your local time, and you can then run either `hwclock --show --utc` or `hwclock --show --localtime` accordingly.

[nooby]

# cat /etc/adjtime
-0.010652 1315034785 0.000000
1315034785
LOCAL
# hwclock --show --utc
Sat 03 Sep 2011 02:40:48 PM CEST -0.856308 seconds
# hwclock --show --localtime
Sat 03 Sep 2011 12:41:24 PM CEST -0.548380 seconds
#

Looking at the clock on the desktop it says 12.42 so that is local time which I also chose when I install a new puppy.

so the norm or standard is to set harware to gmt? That explains why it showed one hour wrong for years then

somebody could have told me Good that you do it now

Edit. This one looks very odd to me


# hwclock --show --utc
Sat 03 Sep 2011 02:40:48 PM CEST -0.856308 seconds

Does not make sense at all. I hate to go into BIOS. Do I have to?

[disciple]

# hwclock --show --utc
Sat 03 Sep 2011 02:40:48 PM CEST -0.856308 seconds

Does not make sense at all.

If you looked at `hwclock --help` you would see that this is telling you what the time in your selected timezone is if your hardware clock is set to UTC. But your hardware clock is actually set to localtime, so this is not the correct time in your timezone.

[nooby]

That made sense indeed. So me being a noob did not know that the CMOS RTC should be set to UTC created a lot of trouble for me for years

So if I get it. You recommend that I go to BIOS and set it to UTC

or use a software that can change the RTC to UTC. I think the E17 had an app that could do that. It at least promised to be able to?
the bad thing for me would be that each OS I have installed already. all the puppies and knoppix and slitaz and tinycore and porteus and archiso and a lot of OS that I don't remember now that I ahve installed already oh Peppermint. Lubuntu and some more. all of them will go the wrong time and would need some reinstall or a change of clock somehow? So much work

[disciple]

That made sense indeed. So me being a noob did not know that the CMOS RTC should be set to UTC created a lot of trouble for me for years

So if I get it. You recommend that I go to BIOS and set it to UTC

Yes I do recommend you have it set to UTC, for the reasons Pizzasgood explained, but you will need to tell Puppy that it is set to UTC.

or use a software that can change the RTC to UTC.

See Pizzasgood's thread.

all of them will go the wrong time and would need some reinstall or a change of clock somehow? So much work

If all your OSs currently think your hardware clock is set to local time, there is no reason you can't leave it that way (you haven't reported having any problems with the clock currently, have you?). It just means you will need to keep updating your clock manually for summer time.

N.B. if anyone is wondering why Linux does not automatically change the clock for daylight saving / summer time when using local time for the hardware clock, think about it: even if you had no Linux, what if you were dual booting two copies of Windows (this used to be more common than it is now). Both copies would change the clock when it came time for daylight saving / summer time, so the time would be incorrect. The same thing would occur if you changed time zones. The Microsoft way does not work - Windows is stupid.

[L18L]

disciple,
thank you for your explanations.

And I have to correct my observations.
I did not expect this:

3. N.B. that GMT+## and GMT-## settings in fact mean the opposite to what you would expect... but the timezone selector gui in Puppy (or at least in my old version) swaps them around so they do work the way you would expect.

Because puppy was showing my time as GMT-1 though I had selected GMT+1 I was thinking that was the reason for the deviation of 2 hours.

But control is better than just think:
I have controlled my BIOS time and found that it was 2 hours wrong !

Corrected BIOS time and now my puppy time is correct too.
I can live with the indication of GMT-1

Back to the OriginalPoster: Did this help you or do still think your puppy is buggy?