Time lags by exactly 3 hours always.
 

Slackware 14.0

Hi: the time in my computer is always lagging exactly 3 hours. I set the right time but in a very short time it is lagging again. What can be the cause?

Since you're exactly 3 hours behind UTC, my guess is that it has something to do with that. Are you dual booting? Also, how are you setting the time?

I'd suggest using timeconfig to make sure that your timezone is correct. Then, make sure the clock is set to the proper local time. Once you've done that, use hwclock to save it to the hardware clock.

If your hardware clock uses UTC:

/sbin/hwclock --utc --systohc

If your hardware clock uses local time:

/sbin/hwclock --localtime --systohc

If you happen to be dual booting, the other operating system might have a different idea about whether you are using local time or UTC. If that is the case, and if it is set to synchronize from a network clock source, that could also lead to a 3 hour offset. Similarly, a wrong timezone setting on Linux combined with network time sync could lead to the 3 hour offset whenever the sync occurs.

I use dual booting but seldom boot the other OS. So, this can't be the cause. Also, the clock must be synchronized to some external source, and this is what I do not understand. I do not use ntpd or other network time service.

Another thing is that when in London it is, say 11pm, in my city it is 8pm. But I have 5pm! Just the same lag but opposite sign. It surely is a coincidence.

The actual UTC time is not relevant. If your hardware clock is set to local time (8 pm), but the system is configured to think that the hardware clock represents UTC, you'll be lagging by 3 hours.

Did you try reconfiguring and then saving the time to the hardware clock?

Yes, I did. Now I'll have to wait at least a day to be sure the clock is well. But why am I connected to an external source? Running 'ps -e|grep ntp' gives nothing. Maybe the GUI runs some network time service?

You might not be syncing to any external source. The example I gave where the hardware clock holds localtime but the system thinks that the hardware clock holds UTC would cause a 3 hour lag for your timezone whenever the hardware clock is fetched.

Hope it works. Good luck!

Thank you very much.

In order to synchronize system clock and hardware clock, both must be set to the same time.

In this article,, I found these instructions:
Ntp is used to synchronize your computer to an external source which is in turn synchronized to an atomic clock at a research facility. It helps to overcome any creeping errors in time reporting due to hardware issues that are too technical for me to describe.

I ran timeconfig to set the time zone to my time zone, then date to set the time and 'hwclock --localtime --systohc'. Now I am periodically running 'hwclock ; date' to see which one of the clocks is lagging, if it is. It is possible that the time zone was wrong. It's the only possible explanation.

The timezone must have been wrong, because after running timeconfig the problem never occurred again. Now the system time is always correct, within the accuracy of the hardware clock.

If you are dual booting with Windows do NOT set your hardware clock to UTC.
Use localtime. Slackware will not add by default server entries to your
/etc/ntp.conf file, you must add them yourself:

Take in care ntp daemon will not correct automatically your time if the delay
is big, so you must stop it:

set the time with ntpdate:

and restart it:

Now I am not using Slackware I don't remember if some rc file runs hwclock at
shut down. You can check it doing:

If it doesn't you can add some of the hwclock commands explained by Patrick to
rc.local_shutdown

In the case of using Windows more than Linux (not your case) you should not use
ntpd and let Windows set the time.

Take in care that an old CMOS battery could be the cause of the problem.

Walter

I suppose Windows connects itself to external sources on a periodic basis. How can this interfere with ntpd?

Windows does do what they call "Internet time" periodically to keep the clock(s) up to date. So, you might want to double-check your time zone settings in Windows and make sure it's correct.

Daylight time is coming soon (it's 10 March in the US) and your Linux system, if it's running, will switch the time. If you then boot Windows, it'll switch the time again, then you get back into Linux and your clock is all screwed up. Best solution I've found is to turn off the automatic daylight time adjustment in Windows. Other best solution is install Windows in VirtualBox (or some other virtual machine software) and you won't have the problem (Windows can't fiddle with the hardware in VirtualBox, but turn off the automatic daylight time adjustment anyway).

You're right, I didn't explain it correctly.

It's not exactly about using ntpd but using UTC time (like Patrick explained). Windows doesn't support UTC bios time, it will save your localtime to bios clock. When you reboot to a Linux configured to use UTC, ntpd won't sync because it can't handle big drifts.

I told you not use ntpd in that case because a common alternative is running ntpdate at boot time.

I think this is bad advice and will hit you every time you change from winter time to summer time and back.

PS: of course you have to use a certain registry setting under windows to make it assume the RTC time is in UTC

I was using bios UTC time for years now (not dual booting), I've ignored till
now that Linux is not able to manage DST changes using bios localtime and that
it is posible set UTC in Windows.

I've found the windows registry entry you mention here:

https://wiki.archlinux.org/index.php...UTC_in_Windows

Good to know that.

Thanks Martinus2u!

Ufff, dual booting, the first thing that occurred to Patrick, was responsible. Or rather my not choosing the proper timezone in Windows together with the fact that Windows was set to adjust time based on internet sources. My timezone (Windows) was Central Time (-6.00) when in fact mine is -3.00. That's why my clock led by exactly 3 hours!

Central Time is US Central (i.e. Texas):

Can you explain the meaning of ART? It seems Locale's full weekday name, 24-hour and minute, HH:MM:SS by the man page but in that case I do not understand CST.

The three-character abbreviations are the time zone; in the conterminous US, there is Eastern, Central, Mountain and Pacific, there is Standard time and Daylight time and there is Time: thus, EST, CST, MST and PST during "normal" months and EDT, CDT, MDT and PDT during "daylight savings" months (Alaska and Hawaii are far west of those zones, they abbreviate as AKST and HAST).

The ART is simply the country code (AR) and Time (seems like Argentine only has one time zone?).

"Wide" countries have multiple time zone and the three- or more character codes are just a way to keep things on track. The basic rule is that every 10 degrees east or west of Greenwich is one hour; that's not political, it's physical. The way the time zone are carved out, though, is political (look at a world time zone map and you'll see that -- no straight lines there). This one is kind of cute: http://www.timeanddate.com/time/map/. There are places on the planet where some time zones are in half-hours (gotta wonder about that).

And all along, Windows had your clock screwed up. Oh, well.

Hope this helps some.

Thanks for the find. It's been a while since I've dual-booted. :)

Argentina has two different times since some years now. And since about the same time we do not have daylight time. But should not the fact that we use standard time be reflected in 'ART', and be 'ARST'?

A remark that comes to my mind is, why so few man pages speak about the format of the command output? Example, 'date'.

stf92,

Try the opposite settings than suggested by eloi in post #11.

The Linux thing

I don’t bother too much with the time settings in BIOS.

When I run timeconfig I choose the option „Hardware clock is set to UTC” and I set the right time zone („Europe/Warsaw” in my case though „Europe/Paris” does the same – sets the time to the Central European one). Then I use date command to set the right date and time. Finally I run hwclock --systohc command to write the right time to BIOS.

In /etc/rc.d/rc.local_shutdown I set the same command:

In /etc/rc.d/rc.local I set the commands:

When I need to change the time I use the mentioned date and hwclock --systohc commands.

I don’t bother with --utc and --localtime switches because hwclock recognizes the valid settings using /etc/hardwareclock file.

The Windows thing

When you use dual booting with Linux and Windows the latter system spoils the time at the turn from the summer to winter and from the winter to summer (Widows makes the correction already made by Linux). To disable that find in Windows the time settings and switch off the correction for the summer/winter time.

The time thing

To check the right time in the different time zones use the following site:

http://www.timeanddate.com/library/a...ons/timezones/

The date thing

What’s missing in the man date in your opinion?

I'm not quite done with this problem it seems, and for the moment I made this: Went to windows and disabled the network thing, leaving daylight disabled too. Now I'm waiting to have stable symptoms before I take any measure.

As to your advices, I'll try them later, not now as I have said. The saving of system time to the hw clock at shutdown, I think the OS does it by default, but I'll have an eye on it.

"What’s missing in the man date in your opinion?": Maybe I should know the meaning of ART but could not the manual say a word about the way the output specifies the country code and daylight condition?

stf92

The date command reports the time zone (“CET” in the following example).

date
It doesn’t display country/region because different countries or regions use the same time zone – for example CET/CEST is used in France, Germany, Poland etc.

To display the time and the date in the different time zones use my script:

time+date
For example:

time+date America/Buenos_Aires
or:

time+date America/Buenos_Aires -l
(In the above example the first line displays the local time.)

Avoid time zones abbreviations because they are sometimes ambiguous and – as a result – display invalid values:

time+date ART
To display the daylight conditions use the command:

zdump -v ART
or the command:

zdump -v America/Buenos_Aires
(The output was too long to quote it all.)

There is a tide in the affairs of men.
Which, taken at the flood, leads on to fortune;
Omitted, all the voyage of their life
Is bound in shallows and in miseries.
On such a full sea are we now afloat,
And we must take the current when it serves,
Or lose our ventures.

(William Shakespeare, Julius Caesar)

I do not want to look at the book now, but that must refer to Casius, or Casius trying to convince Brutus. Anything to do with the thread? Oh, now I got it!

Your later is my now:

time+date America/Buenos_Aires -l

Very good.

You’re right: /etc/rc.d/rc.0 and /etc/rc.d/rc.6 do that. My settings are very old. Probably in those old times the system didn’t save the system time to the hardware clock so I had to do that. Or maybe I just doubled the default settings in /etc/rc.d/rc.local_shutdown unconsciously.

That is why I asked. Did not want to double them. Personally I prefer personal control over automation.

I liked the manual control when it took a few hours to configure a newly installed system. When my system configuration became so sophisticated that it started to take more than one day to restore that configuration in a newly installed system I started to develop my set of the installation and configuration scripts.

Since that day I don’t touch any configuration file manually when I need to change something in the system. Instead I add the procedure to the appropriate configuration script and I run it once again.

As a result when the new system version appears I install it and than I run nine scripts which configure it. The whole procedure takes a few minutes (including two reboots).

I'm developing a homebrew computer around a microprocessor from the late seventies. I assure you I have total control. I mean, I like little systems because one can know them through, but there is enough complexity not to get bored.

You talk about learning a new things. I talk about repeating the same actions again and again. The first is good (or interesting) – the latter is bad (or boring). I assume we both like to learn some new things and we both dislike to do exactly the same things in a continuous loop.

That's the good thing about programming. Anytime a thing gets boring because of repetition or great mental focus, you can make it automatic. Of course this time the automation comes from you. Many people say, "but I have to do it now, it's faster if I do it manually". Most likely it'll have to be done again, and again.

I knew that we have a lot of more or less modern versions of Shakespeare’s works in Polish language but I didn’t know that English-language people have some modern version as well:

Original text:
Modern text:

Just for fun:

I left Argentina in 2001. I remember that government decided
each year if using daylight time or not, if one or two hours.
If someone want to know what "improvisation" is go to Argentina
:). Here is well explained:

http://es.wikipedia.org/wiki/Hora_oficial_argentina

This resume in english is useful:

http://simple.wikipedia.org/wiki/Time_in_Argentina

In a desktop I would change the time manually. I would use UTC
on the whole machine on a server. Perhaps someone esle has a
better idea.