If Carlos would note in my original reply that I said "... it's all relative", then some sense can be made of this mess about time, clocks, etc. First of all, any _nix system only knows the time if you tell it what it is (actually, that's true for any puter). The cmos clock on the mb is generally referred to as the hardware clock and can be read with "hwclock -r". In my system the hc value is tested against the settings in /etc/adjtime and the result is presented to the system for use: display, cron, etc. Here's the relative part: the system thinks it is default UTC, but you can have it believe anything. The correct UTC might be 3am but you can have it set to 9pm. All the system will do is apply local time zone offsets from its perceived utc value IF "local" is included in adjtime. So, don't say that a _nix internal clock is UTC when, in fact, it is whatever you want. UTC is French for Universal Coordinated Time, which is the politically correct way to say Greenwich Mean Time which, of course, refers to the old observatory and the might and extent of the British Empire. I, being Texan and not caring a hoot about anything British and especially not French, do not set my clock to London time. Semantics, anyone?
Stevens wrote:
First of all, any _nix system only knows the time if you tell it what it is (actually, that's true for any puter).
It is certainly true that any entity, whether a computer or a person, only knows the time it is told. But it's hardly relevant.
Here's the relative part: the system thinks it is default UTC, but you can have it believe anything. The correct UTC might be 3am but you can have it set to 9pm.
Well, if you plug a GPS card in or use an NTP daemon, you'll find that all times are NOT equal after all. And if you expect it to change local daylight savings automatically at the correct time with the official database, then you'd better have the system time set to UTC. All you're saying is that you can set clocks incorrectly.
All the system will do is apply local time zone offsets from its perceived utc value IF "local" is included in adjtime.
So, don't say that a _nix internal clock is UTC when, in fact, it is whatever you want.
A _nix clock *IS* UTC in the sense that that is how it is designed. The fact that you can set a particular _nix clock incorrectly is hardly news and certainly isn't relevant.
UTC is French for Universal Coordinated Time,
not correct (the French would be TUC for temps universel coordonné - UTC was specifically chosen to be neither French or English)
which is the politically correct way to say Greenwich Mean Time
not correct (UT is the politically correct way to say GMT)
which, of course, refers to the old observatory and the might and extent of the British Empire.
You're evidently not a sailor or pilot. It refers to maps and longitude and the necessity for shared understanding for navigation. And nowadays that shared time is vital for communications circuits, television etc.
I, being Texan and not caring a hoot about anything British and especially not French,
I see we share a love of the French, though :)
do not set my clock to London time.
London time is never UTC - it varies between BST and GMT. Cheers, Dave
Dave Howorth wrote:
Stevens wrote:
which is the politically correct way to say Greenwich Mean Time which, of course, refers to the old observatory and the might and extent of the British Empire.
PS The decision to make universal time was taken in the US at the instigation of the US president and the US voted for Greenwich.
Stevens wrote:
If Carlos would note in my original reply that I said "... it's all relative", then some sense can be made of this mess about time, clocks, etc.
First of all, any _nix system only knows the time if you tell it what it is (actually, that's true for any puter). The cmos clock on the mb is generally referred to as the hardware clock and can be read with "hwclock -r". In my system the hc value is tested against the settings in /etc/adjtime and the result is presented to the system for use: display, cron, etc. Here's the relative part: the system thinks it is default UTC, but you can have it believe anything. The correct UTC might be 3am but you can have it set to 9pm. All the system will do is apply local time zone offsets from its perceived utc value IF "local" is included in adjtime.
So, don't say that a _nix internal clock is UTC when, in fact, it is whatever you want. UTC is French for Universal Coordinated Time, which is the politically correct way to say Greenwich Mean Time which, of course, refers to the old observatory and the might and extent of the British Empire. I, being Texan and not caring a hoot about anything British and especially not French, do not set my clock to London time.
Semantics, anyone?
OK, that part makes sense to me, but why didn't the time change automatically on Sat. night. Thanks, -- ED --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 09:56 -0500, Ed McCanless wrote:
OK, that part makes sense to me, but why didn't the time change automatically on Sat. night.
There different scenarios for this, and difficult to say which one applies to you. Supposing the system time was correct and the time zone correct, and the computer is running at the time, you can see the time go back one hour at the precise moment (I didn't in fact). Look: 29 Oct 01:39:01 ntpd[4353]: offset 0.060212 sec freq -45.497 ppm error 0.218041 poll 8 29 Oct 02:15:14 ntpd[4353]: synchronized to 88.*.*.23, stratum 2 29 Oct 02:28:43 ntpd[4353]: synchronized to 195.*.*.112, stratum 2 29 Oct 02:39:01 ntpd[4353]: offset 0.075185 sec freq -40.442 ppm error 0.146961 poll 9 29 Oct 02:50:26 ntpd[4353]: synchronized to 193.*.*.30, stratum 2 29 Oct 02:10:45 ntpd[4353]: synchronized to 195.*.*.112, stratum 2 29 Oct 02:12:02 ntpd[4353]: synchronized to 194.*.*.200, stratum 3 29 Oct 02:12:02 ntpd[4353]: time reset +0.248788 s 29 Oct 02:12:02 ntpd[4353]: system event 'event_clock_reset' (0x05) status 'leap_none, sync_unspec, 15 events, event_peer/strat_chg' (0xf4) See how after the 02:50:26 comes another at 02:10:45, ie, backwards? Notice that this is only the displayed time, the internal time remains unchanged, at UTC. In fact, you can have different users with different time zones, and see the time going back one hour at a different time for each one. If the computer is booted after the time change, things are different. The CMOS clock (or hardware clock) maybe set to "UTC". This is the least problematic, the boot script read the time and runs "hwclock --hctosys - --utc". No calculations needed. The CMOS clock (or hardware clock) maybe set to "local". In this case, it runs "hwclock --hctosys --localtime" instead, meaning that it has to calculate the UTC first before setting up the internal system clock. Assuming the Linux programmers did it right, and that your system time zone (the one for root) is correct, the time will be set up correctly. But you see that there are more places for error here. Now, the worst case: you booted windows before linux, and after the time shift. Windows always assumes the CMOS clock is set to local time, and noticing that the last time it was running was before the official time change, it will change it, and it will also change the CMOS clock time - so that when linux boots the time will already be shifted and it will get the incorrect time. Or any combination of the above problems. In order to check, issue the command "date" as root, and see if the time and timezones are correct for you. Ignore what kde clock says. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRiSLtTMYHG2NR9URAt8OAJ9YbCIYi/WWR26ewySmHUg3L5L2hQCdGpWy i3pBCzt/07+AHtmtjJXocHI= =7MTk -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-- SNIP --
In order to check, issue the command "date" as root, and see if the time and timezones are correct for you. Ignore what kde clock says.
Thanks Carlos, Studying this has reminded me of an occurance about 4 - 5 days ago. At boot, (I still turn of at night) I noticed the time being slow by more than one hour, and re-set the clock. We've had some power outages recently, and I gave it little thought (not thinking of the CMOS battery.) But, if the change came that early, I can't figure any reason for that either. It would be more comforting if the change were only early or late by 12 hrs. I guess I will run the checks you advised, and wait for the next time change. -- ED --
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 15:31 -0500, Ed McCanless wrote:
Studying this has reminded me of an occurance about 4 - 5 days ago. At boot, (I still turn of at night) I noticed the time being slow by more than one hour, and re-set the clock.
Unfortunately, setting the time in linux is not as straight forward as it should be. For instance, you set the system (OS) time using a command. When the computer is powered off, that time is copied to the CMOS clock, but, as it is different, the program is too clever and thinks that it has to compensate for the difference, and stores a compensation factor in /etc/adjtime. The next time you boot, the factor kicks in and corrects the time... to an incorrect value. So, the procedure is to set up the system time (OS time), copy it to the cmos, and finally, erase the /etc/adjtime file. Simple, eh? Ufff... :-P Another way, is to set the clock in the bios setup page before booting. That way Linux doesn't notice a thing.
We've had some power outages recently, and I gave it little thought (not thinking of the CMOS battery.) But, if the change came that early, I can't figure any reason for that either. It would be more comforting if the change were only early or late by 12 hrs. I guess I will run the checks you advised, and wait for the next time change.
That's 6 months away! Too long to wait, I would surely forget it. If you are that interested, you can run checks setting the time incorrectly to some minutes before the time shift (by the procedure above). But beware! Linux doesn't like at all somebody playing with "his" clock, and behaves in some nasty or unexpected ways (depends). Cron jobs starting suddenly, etc. I did that once... entertaining ;-) - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRphmtTMYHG2NR9URAiUlAJ4uBMnAAFP5mwba0t2Q12fvYZ1h6ACfWx5H tL9vZNnrW3psII2hXj0rhF0= =+xVz -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-- SNIP --
In order to check, issue the command "date" as root, and see if the time and timezones are correct for you. Ignore what kde clock says.
Thanks Carlos, Studying this has reminded me of an occurence about 4 - 5 days ago. At boot, (I still turn of at night) I noticed the time being slow by more than one hour, and re-set the clock. We've had some power outages recently, and I gave it little thought (not thinking of the CMOS battery.) But, if the change came that early, I can't figure any reason for that either. It would be more comforting if the change were only early or late by 12 hrs. I guess I will run the checks you advised, and wait for the next time change. -- ED --
Stevens wrote:
So, don't say that a _nix internal clock is UTC when, in fact, it is whatever you want. UTC is French for Universal Coordinated Time, which is the politically correct way to say Greenwich Mean Time which, of course, refers to the old observatory and the might and extent of the British Empire. I, being Texan and not caring a hoot about anything British and especially not French, do not set my clock to London time.
Actually, UTC is atomic clock time, which is slightly more accurate than the GMT astronomical clock.
Dave Howorth wrote:
James Knott wrote:
Actually, UTC is atomic clock time, which is slightly more accurate than the GMT astronomical clock.
No, TAI is atomic clock time. UTC has a fudge factor called 'leap seconds'.
So, which is the best one to use for my VCR clock? ;-)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 16:30 -0000, Dave Howorth wrote:
James Knott wrote:
So, which is the best one to use for my VCR clock? ;-)
Well I wouldn't use atomic time unless you want it to glow in the dark :-)
Mine does glow in the dark :-P - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRl9jtTMYHG2NR9URAr3YAJ46Ev7H2xh2fFNzzJ4aux2xvd2nNQCcDiPK aDrgyMW2I0oFnMxqO16/N1I= =cWIH -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-10-30 at 08:03 -0600, Stevens wrote:
If Carlos would note in my original reply that I said "... it's all relative", then some sense can be made of this mess about time, clocks, etc.
First of all, any _nix system only knows the time if you tell it what it is (actually, that's true for any puter). The cmos clock on the mb is generally referred to as the hardware clock and can be read with "hwclock -r". In my system the hc value is tested against the settings in /etc/adjtime and the result is presented to the system for use: display, cron, etc. Here's the relative part: the system thinks it is default UTC, but you can have it believe anything. The correct UTC might be 3am but you can have it set to 9pm. All the system will do is apply local time zone offsets from its perceived utc value IF "local" is included in adjtime.
The fact that the "adjtime" file contains the word "local" doesn't affect in any way the the internal, system, or software clock (all names for the same clock), which still maintains UTC, regardless of that file. The "local" or "utc" word in that file means that the CMOS, or Hardware, or Bios clock (all names for the same device) stores local or utc time. It is used only during boot (man hwclock). You are confusing concepts. It is true you can lie to the system and tell it a different hour. Right. But it is a very difficult lie to maintain. For instance, the moment you fire up any network time setting program, it will adjust your clock to UTC, internally - unless you modify the sources of such a program. The internal time is simply a counter storing the number of seconds since 00:00:00 UTC, January 1, 1970 (man time). Based on that internal time, when the time is displayed to the user, the local time is calculated from the time zone and dsl settings (ie, your locale). You can have many different time zones in use, one for each user of the system. If you set the internal time to something else than UTC, when the time is displayed the system will add to it the displacement known from UTC to Local time - therefore, you will have to give your setup a different time zone than the real one so that the time displayed appears to be correct. No, the internal clock will run UTC. Even if I set it up giving it my local time, it does a calculation and internally sets UTC time. You can not change it unless you modify the kernel sources and many other programs. Did you?
So, don't say that a _nix internal clock is UTC when, in fact, it is whatever you want.
Utterly impossible.
UTC is French for Universal Coordinated Time,
No, it is English for "Coordinated Universal Time". The initials were chosen so that the order is incorrect both in English as in French, on purpose, so that no one could claim that UTC was "theirs". - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFFRh+QtTMYHG2NR9URAtH4AJ0QC3n/N/LT56mj8AtqU9t5/mSqkACffHDA Nl4Bv8W8QLqJ0u4vxtGxE64= =lLk7 -----END PGP SIGNATURE-----
participants (5)
-
Carlos E. R. -
Dave Howorth -
Ed McCanless -
James Knott -
Stevens