I posted a thread many months ago, when my desktop clock (the KDE applet) was consistently 3 hours off, despite my timezone being correct and my BIOS clock being also correct.

Since then, I got that straightened out (off the top of my head I can't recall how, but it had something to to with the timezone and/or 'localtime/UTC').

The problem now:

Desktop clock applet is correct.
BIOS clock is correct.
The DATE command shows:
sasha@darkstarSSI:~$ date
Thu Sep 27 15:25:18 UTC 2007 (correct)

But I have noticed lately that my cron-jobs are running 3 hours late!?!

In the interest of saving electricity, I have been shutting down the computer most nights. I have it set to turn on by RTC at 6:45am because the daily backups are done by cron starting at 7:00am. However, by the time I get on the computer and then 10:00am rolls around, the darned backups start going.

AaAaAaRgh!! LOL, does anyone have a suggestion as to what the heck is wrong with which aspect of which time-keeper in this machine?? Maybe something to do with the hctosys or systohc on boot or shutdown? I don't know. And on the subject of the systohc and hctosys, do I *really* need either/both of them? Isn't the BIOS clock enough? Or maybe hctosys on boot, but no systohc on shutdown?

It's Slackware 11, E2160, umm.. The RTC is onboard, not external.. Not much else relevant to this..

Thanks!

/etc/localtime and/or /etc/timezone look correct?

@ rshaw - far as I know, they are correct..
When I installed Slack waaaay back, I did set the timezone to my local timezone America/Halifax which is where it stayed until I eventually realized that the clocks were messed up, back when I posted the other issue.

I just went to the 'Date/Time' configurator from my main menu a few moments ago, and when I opened it up, it was 3 hours behind (despite my system time and desktop applet being correct) and it was set to America/Halifax. I adjusted the clock 3 hours to the correct time, and ACK! The desktop clock went 3 hours AHEAD! All the while, the 'date' command returned the correct date and time in a console.

So, I changed the timezone to UTC (again) and set the /etc/localtime to UTC also, and now the clocks are in sync again (as well as the BIOS is correct) so it all *looks* good, but I will hafta wait till tomorrow morning to see when the cron jobs run, to see if anything has really changed.

Seems maybe I never really did get the first issue way back solved properly after all :S

i just love multiple config files for the same thing. (what's reading who from where?)

anyway, good luck

Do you dual-boot this box with 'doze by any chance ???

NO! No 'Doze here folks

So, it is right that you have local time in your system clock, but call it UTC for the system? Maybe cron uses "local time" as in "BIOS clock - 3 hours", if it somehow found that you left a mention of your TZ?

I would set BIOS clock to real UTC and choose correct timezone.

Now THAT is something I hadn't considered! If this persists today, I will give that a shot.

Спасибо, Раскин!

Well, I hesitate to say the problem has been 'properly rectified', so for the moment, let's say it has 'gone away'..

Currently my desktop clock is correct, my TZ is set to UTC and /etc/localtime is also set to UTC. `date` returnd the correct date & time, and *I think* my crons happened on schedule today. Woohooo!
Now you watch, next time I look into the BIOS, I'll see the time is 3 hours off LOL, HOWEVER, if it IS, I shall assume until I investigate further, that the correct time UTC is what I'm reading there, and per Raskin's concept, that's how it should be..

BTW, what the heck IS UTC?? I know what it stands for, but-- WHERE is it? Greenwich (like GMT) or what? Ha! Time for Google...

OK, now your problem is more like stalled. What you have done is not a correct solution, though it will work for a while (it works for Windows..). The first time you try to use NTP (network clock synchronization) or something like that, you'll get a headache. An honest, though not the best way, is just explaining to your Linux that you have local time in BIOS and your timezone is the following. To do that, change timezone back, and in /etc/sysconfig/clock (or somewhere in /etc) look for UTC= . Flip the value (put 0 instead of 1, or "no" instead of "yes"). Another way is to put UTC (yes, it can be used as if it were GMT+0 without DST - I am not sure if there ae differences, but they are under 1 second) in BIOS clock. The only drawback I can imagine is if you have Windows. It has too little clue about timezones.

According to what I just read about NTP and the NTP service, I need broadband to use it anyhow. I have 28.8K dialup unfortunately, so that's out of the question.

I don't have Windows either, so that's irrelevant.

Now, one reason I would like to simply have THE TIME, as opposed to needing to actually set my timezone somewhere, is because when I DO have my local timezone info incorporated into the Linux, the silly clock on the toolbar insists on writing 'America/Halifax' underneath the clock. As you can imagine, a 3/8" thick toolbar does not accomodate a readable clock, with text underneath it, very well. Both get so small as to make them near useless. I prefer just having the clock itself, which means I need no timezone designation associated with it.

So.. If I set my BIOS to the correct localtime, and tell Linux that the BIOS is in UTC, then as long as no system services (like cron) are computing the localtime (and how could they if I tell it I use UTC) everything should work like... Clockwork! Correct? And as long as I manually change the BIOS clock for DST, when appropriate, all should be well, correct?

And PS - the file /etc/localtime contains simply UTC. There is no value (true/false/yes/no/1/0) associated with it. If I set the timezone to my local timezone, then the file contains localtime, again with no values or modifiers. The actual information associated with the indicated timezone is derived from the 'timezones' portion of GlibC.

BTW, if you would be so kind, please explain what 'headaches' I would encounter under my current setup, if one day I were to be able to use the NTP service? I guess I would HAVE to use my local timezone somehow then, huh?

Well, it looks like your machine can be considered not exchanging any sensible timestamps over Internet, so pseudo-UTC setup should work OK. I didn't think of silly clock (well, it is probably possible to fix it without recompilation, but the option to fix can be buried in some config file one cannot find while sane), because I use xterm+shell script as clock. Thanks for information about UTC/localtime switch in Slackware - every distribution does it in its own way.. About NTP headaches - well, I would find it annoying when clock goes 3 hours ahead at unpredictable moments. For added points, NTP update in such situation sometimes forces screen saver to start. It is not hard to stop using it completely, though (unlike Windows, where it took me some time - Linux used UTC, Windows cannot; I am not against seeing UTC, but against leaping clock; so clock update had to be off in Windows).

Yes, 'leaping clock' would be annoying for sure.

Incidentally, my screensaver often DOES suddenly activate if I change the date/time using the Menu --> date/time method, but it's more than just 'activate'.. It seems that X actually either changes modes momentarily, or something along these lines. I say this, because normally my screensaver is silent, as it should be, but my monitor is built with a relay inside it somewhere, which clicks on then off, when there's a resolution change. Normally the screensaver doesn't make it click-click, but when changing the time, it does, 'click-click-screensaver'.. Bizarre..

Well, sincere thanks again, for your input, Raskin

NTP is designed in such a way that it may be used reliably with dialup connections. Just FYI.

Really? Well, I had just quickly scanned thru the Wikipedia page on UTC, which led me to my current state of "about 10 tabs open to various things about time, NTP, etc.." one of which I got that idea from, so I will check into that again, and/or read more carefully! Thanks for the tip and if I DO end up using it, I'll let you folks know how it's configured in the end.