BIOS time and Puppy time (ANSWERED)

[Béèm]

In polarpup in var/log/messages I am already 5 september.

[nooby]

... If the BIOS clock is in local time, the error message will be generated because at this point the filesystem checker thinks that the BIOS clock is in UTC.

This would be essentially the same problem as https://bugs.gentoo.org/142850?id=142850. One of the guys there was recompiling his kernel twice a year for daylight saving, which doesn't seem very sustainable

But it looks like they have found the workaround for this problem in comment 42.

Since the default is for Puppy to use a BIOS clock set to local time, ...we should be encouraging people to set their BIOS clock to UTC, instead of following Microsoft's stupidity.

I have set my Bios time to UTC now. So I don't have to recompile Gento. Hahah what a core.

So as long as one have Bios to UTC then everything will be okay?

Sounds assuring

[nooby]

Damn I fail to get this. I mean logically but okay I always fail with logic.

Local time here is 22.01 or so I did this some minute ago.
# hwclock --show --utc
Sun 04 Sep 2011 11:59:19 PM CEST -0.585188 seconds
#
UTC is also known as Universal Coordinated Time
Current Time Sunday, 4 September 2011, 20:01:31

that is the true UTC and that was what I told BIOS to set it too.

So this hwclock --show --utc seems to not give true time of the hardware
or the hardware are reset to puppy time when puppy boot up?

What is going on?
Ooops should say that after correcting BIOS then puppy was one hour wrong so I corrected that one and now it show this gross error.

[tasmod]

Beware, hwclock reads the bios time BUT reports in localtime format.


Using GMT has always caused problems in Puppy, not least because Puppy reverses the notation + to - and vice versa.
It is best to run the locale setting to your location. i.e. Europe/London

The problem also shows because the 'clock' in the tray is another app that reads the time and 'plays' with it in script.

I'm not sure about 3.1 but maybe try my app Psync from the forum Additional Software/system section to see if it will run in 3.1.
Set your locale (reboot) and run the app, select a Region nearest to you (probably UK) and the app will do the rest. your time will be synchronised to within millisecs to 'standard' time. It will correct up to a day out !!

If it works it's also worth clicking the Help button for explanation on 'time'.

[nooby]

Rob tasmod what you say now goes 180 degree counter to another member in the thread.

So whom should I trust apart from me maybe misunderstood.

can not you and him talk about it and explain to each other why you come to opposite conclutions?

disciple here
http://www.murga-linux.com/puppy/viewto ... 988#559988

To go out on internet and get sync time is to have a constant thing going on. It is not something I like at all. Can one set it to do it at boot up and maybe at shut down or something . Not all the time.

[nooby]

edit went wrong

[MinHundHettePerro]

nooby,

do you have a file /etc/clock?

What's the output of

Code: Select all

# cat /etc/clock

?
I'd wager it's "HWCLOCKTIME=localtime" and not "HWCLOCKTIME=utc".

hth /MHHP

[nooby]

# cat /etc/clock
#Set this to either 'utc' or 'localtime' based on which one your computer's
#hardware clock uses.
HWCLOCKTIME=localtime
#HWCLOCKTIME=utc

#
I do it again
# cat /etc/clock
#Set this to either 'utc' or 'localtime' based on which one your computer's
#hardware clock uses.
HWCLOCKTIME=localtime
#HWCLOCKTIME=utc

It gives both or what?
How can I change.

And what to do about Disciple saying one thing and tazmod Rob something opposite and I fail to get what both talk about

I guess it means you are right but where do I change that one then.

okay personal settings most likely. I take a look

[MinHundHettePerro]

nooby,

either you change

Code: Select all

HWCLOCKTIME=localtime
#HWCLOCKTIME=utc 

to

Code: Select all

#HWCLOCKTIME=localtime
HWCLOCKTIME=utc 

and restart, or you could see if you have the depicted utility in your menu (it's there in slacko-499.1, think I've seen it in other recent pups).

(You did set your BIOS/HW clock to correct utc-time, but your puppy was not told that your HW-clock now is set to utc instead of localtime.)

hth /MHHP

[nooby]

Thanks your an Angel but that one ask if the hardware should follow the software or software the hardware.

I had no idea? Que? So I accepted the first and that set the clock to 01.30 instead of 11.30 PM # cat /etc/clock

#Set this to either 'utc' or 'localtime' based on which one your computer's
#hardware clock uses.
HWCLOCKTIME='utc'
#HWCLOCKTIME=utc

And I have clicked on time and changed back to Sunday and 23.32 something

But we still have that conflict between Disciple telling me that UTC is the way to do it
and Rob tazmod that tells me that local time is the way to go.

I have no idea whom to trust?

I have to go to bed soon. Thanks for caring about me

[MinHundHettePerro]

nooby,

after running "Set hardware-clock type", it seems like you need to set your time again (!), either from within your running puppy, or by venturing into BIOS again...

hth /MHHP

[Bruce B]

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.

That's how it does or at least how it did with 3.01

But the clock on the taskbar reads the same as the BIOS clock. In fact the only way Puppy knew the time is the BIOS clock told it. Unless you are using a remote clock, there was no other place for Puppy to get the time.

And no it is not a Linux trait in general.

There are solutions as well as ways to avoid this phenomena but I don't think Puppy employees them.

~

[disciple]

Rob tasmod what you say now goes 180 degree counter to another member in the thread.

So whom should I trust apart from me maybe misunderstood.

I think you have misunderstood, because tasmod is saying the same thing as me (except I'm not promoting the Psync solution )

Damn I fail to get this. I mean logically but okay I always fail with logic.

Local time here is 22.01 or so I did this some minute ago.
# hwclock --show --utc
Sun 04 Sep 2011 11:59:19 PM CEST -0.585188 seconds
#
UTC is also known as Universal Coordinated Time
Current Time Sunday, 4 September 2011, 20:01:31

that is the true UTC and that was what I told BIOS to set it too.

So this hwclock --show --utc seems to not give true time of the hardware

Like I said before, `hwclock --show --utc` assumes that the BIOS clock is in UTC and tells you what the local time is. So that output is what I would expect. (N.B. When you posted this, Puppy thought your BIOS clock was in localtime, so `hwclock --show` would have produced the same output as `hwclock --show -localtime`)

But we still have that conflict between Disciple telling me that UTC is the way to do it
and Rob tazmod that tells me that local time is the way to go.

I can't see tazmod saying anywhere that you should use local time. You can use either, but if your country has "daylight saving" or "summer time" then it is better to use UTC so you don't need to reset the clock manually (unless you use Windows or Psync or something else which will reset it).

[disciple]

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.

That's how it does or at least how it did with 3.01

But the clock on the taskbar reads the same as the BIOS clock. In fact the only way Puppy knew the time is the BIOS clock told it.

Sure, but the issue is whether Puppy assumes the BIOS clock is set to local time or GMT/UTC. And the default is actually to assume local time, which Mercedes did not seem to realise.

There are solutions as well as ways to avoid this phenomena but I don't think Puppy employees them.

Which phenomena do you mean? The assumption that the BIOS clock is in local time? These days Puppy has an option to avoid that, like we've spent half this thread describing.
Or the "Superblock write in the future" message? I think I identified yesterday the fix/workaround that is needed for that.

[Bruce B]

Disciple,

Mercedes350se post was about version 3.01, my reply was about the same version.

Something changed? I factored that in. Moreover, I think something should have changed. And if it did, it was well overdue.

As for me, you can give me any Puppy and I can get it working right on two clocks as well as a time server.

How I do it is no longer anyone's business. Not meaning to be hard on you, quite to the contrary.

But frankly, I'd like to see if Puppy really can be syncronized with a time server. Windows can.

Sorry if I sound hard, but on this one I am.

Bruce

~

[tasmod]

I mentioned Psync because most people want at least one accurate clock in local time.

Here's an extract from the man page for hwclock.

Clocks in a Linux System

There are two main clocks in a Linux system:

The Hardware Clock: This is a clock that runs independently of any control program running in the CPU and even when the machine is powered off.

On an ISA system, this clock is specified as part of the ISA standard. The control program can read or set this clock to a whole second, but the control program can also detect the edges of the 1 second clock ticks, so the clock actually has virtually infinite precision.

This clock is commonly called the hardware clock, the real time clock, the RTC, the BIOS clock, and the CMOS clock. Hardware Clock, in its capitalized form, was coined for use by hwclock because all of the other names are inappropriate to the point of being misleading.

The System Time: This is the time kept by a clock inside the Linux kernel and driven by a timer interrupt. (On an ISA machine, the timer interrupt is part of the ISA standard). It has meaning only while Linux is running on the machine. The System Time is the number of seconds since 00:00:00 January 1, 1970 UTC (or more succinctly, the number of seconds since 1969). The System Time is not an integer, though. It has virtually infinite precision.

The System Time is the time that matters. The Hardware Clock's basic purpose in a Linux system is to keep time when Linux is not running. You initialize the System Time to the time from the Hardware Clock when Linux starts up, and then never use the Hardware Clock again. Note that in DOS, for which ISA was designed, the Hardware Clock is the only real time clock.

There's more but it wouldn't help here. This is basically what was under my 'Help' button. There's lots of history on the net regarding 'time', not least the argument surrounding GMT and the efforts to take the credit for a standard 'time' by others.

[tasmod]

Bruce,

If Puppy really can be synchronised

Really, yes. Psync does this as you know. However it doesn't use NIST servers but ntp does poll various 'pool' time servers on the net. This 'pool' is constantly changing, that's why Psync uses the 'pool'. It will always have at least 5 servers regionally to check against for a setting. (Latency excepted)

[Mercedes350se]

... Since the default is for Puppy to use a BIOS clock set to local time, ...
But really, we should be encouraging people to set their BIOS clock to UTC, ...

Um, "Why?

As a radio amateur I am quite at home talking about GMT, UTC, Zulu but I would like my computer BIOS and Puppy time to be local. As I said in my original post it is easy to set it up this way! A quick trip into Set timezone twice a year is no hardship.

The System Time: This is the time kept by a clock inside the Linux kernel ... The System Time is the time that matters.

Sorry to repeat myself. Um, "Why?

Having asked that I must thank you tasmod for actually answering the question posed in my initial post.

[Bruce B]

I'll suppose that Puppy never solved the problem. This is speculation only because I don't know.

We have two clocks, the RTC and the System clocks. To get these in synronize these clocks is kindergarten play.

If this is all Puppy can do, it has done nothing. The reason why is anyone can do that.

Many computers keep time in sync with time servers. If you can use those servers and Puppy keeps the time right according to the TZ, then something has been fixed.

If not, work needs be done. All a person needs to is try it.

~

[Bruce B]

The System Time: This is the time kept by a clock inside the Linux kernel ... The System Time is the time that matters.

Sorry to repeat myself. Um, "Why?

The system time is the time that matters is ONLY because it is the time displayed and used.

The system time gets its time from the RTC. It is no more accurate than the RTC. Except theoretically, it doesn't drift as much. But then we have RTC clocks that don't drift much either.

The system clocks are no better at displaying accurate time than the RTC was when it booted.

The system time is software. The RTC time is hardware. Operating systems are not designed to continiously poll the RTC. One poll at boot time is all it takes.

Except Puppy will poll it a couple times likely, at least in the past, to get around the way it deals with the TZ.

The TZ throws the time off. Now what time is it? Poll the RTC and find out.

If someone wants accurate time, poll an accurately set RTC or poll a time server.

~