Local time depends on where you are and may use some sort of daylight savings time. The dates on which wintertime changes to summertime or back is different from country to country (or even region) and may vary from year to year depending on politicians whims.
International time is independent of where you are and does _NOT_
use daylight savings time, summertime or winter time.
There are several (slightly different) versions of international time
and there names are (incorrectly) used interchangeably;
GMT (Greenwich Mean Time), UT (Universal Time) and UTC (Coordinated
Universal Time). When one of these is mentioned one usually means UTC.
And although Greenwich is part of south London, it is _NOT_ a
British, but an international time standard. The British time standard
is BST or British Standard Time and does use summer time.
GMT on the other hand does _NOT_ use any sort of daylight savings
time.
Some sort `human readable' format;
Sat Dec 23 14:22:04 UTC 2000
Or;
Sat, 23 Dec 2000 14:22:04 GMT
The number of seconds since some reference point in time;
The systems above can easily be converted from one to the other by adding
or subtracting the appropriate number of seconds.
The resolution or granularity is not limited to seconds but may have
millisecond (1/1000 s), microsecond (1/1000000 s) or even nanosecond
(1/1000000000 s) precision.
There are numerous applications that rage havoc if your system, or the system you are communicating with, do not keep accurate time. For instance, when you are using a system which automatically replaces old documents with newer versions, an incorrect clock may lead to a new documents being replaced with an older version instead.
The most common example of this, is a browser or even a proxy server,
displaying outdated pages instead of fetching fresh ones, or reloading
old pages as if they where new, when they didn't change at all!
Only if your client (webbrowser) machine is both set to the correct time,
and in case of non unix systems, the correct timezone is set, will your
browser's cache management work correctly.
The same applies to (all) the proxy server(s) you use and all of the
web sites you visit!
Dos, (older versions of) Novell and (older versions of) Windows keep
local time and convert this time to GMT prior to communicating with the
outside world.
This also means that the PC's CMOS clock is set to local time.
Unix and unix like OS-es such as Linux and FreeBSD use GMT internally and
convert the international time to local time when communicating with the
user.
The PC's CMOS clock is usually set to GMT.
Suppose you have got two computers, both set to local time. One you switch
off just before summer time changes to winter time or vv. After the change,
you switch the computer back on. So how do make sure that both machines run at
the correct time?
Obviously, you can't. The only way to make sure that your CMOS clock is set
to the correct time is to set it to GMT.
Both systems need information on the timezone they are in, in order to be able to make the necessary calculations from local to international time or from international time to local time. The difference is usually expressed as a string and or a number which expresses the difference between international and local time. This is either a number which has to be added to local time to get international time (Dos / older versions of Windows) or a number which needs to be added to international time to get local time (unix).
The best thing to do, is to synchronise your computer's clock to an
atomic clock. Or better still, use several atomic clocks and calculate
the average time of all these clocks. You disregard the time from clocks
which are way off and use the clock closest to the average of the
rest of the clocks as a reference source. The reference time is then used
to adjust the speed of your PC's clock.
You don't need your own atomic clock to keep accurate time. There all lots
of atomic clocks connected to a radio transmitter, the internet or both.
If you synchronise to a `radio clock' you need to find out how long it
takes for the radio signal to get to you and how much time it takes to
process the information.
If you synchronise to an atomic clock via the internet, the software will
usually calculate the delay and make the necessary corrections for you.
NTPD is a time server.
If your computer seems to have a different clock speed each time it reboots, have a look at; Kernel 2.6 Mis-Detecting CPU TSC Frequency
For IPv6 NTPD wants hex netmasks. EG;
restrict 192.168.1.0 mask 255.255.255.0 nomodify restrict -6 2001:db8:1234:abcd:: mask ffff:ffff:ffff:ffff:: nomodify
On newer systems that's wihout '-6';
restrict 2001:db8:1234:abcd:: mask ffff:ffff:ffff:ffff:: nomodify
More at; If you used 'restrict default ignore'
Leap seconds usually
trickle down from parent clocks. Sometimes a parent will process the leap
second correctly but won't announce it. In this case a leap second file is
required. You can download a leap second file from the
International earth
rotation & reference systems service website.
Put an entry in your ntp.conf. EG:
leapfile /etc/leap-seconds.3535228800
Parent clocks announce a leap second just under a day in advance. DCF 77 announces a leap second one hour before it occurs. GPS will process the leap second correctly, but won't announce it. You need a leap second file for GPS.
GPS expresses the date as a 10-bit week number. So every 1024 weeks there is a week roll-over;
| Week | Date |
|---|---|
| 0 | 6 Jan 1980 |
| 1024 | 22 Aug 1999 |
| 2048 | 7 Apr 2019 |
| 3072 | 21 Nov 2038 |
| 4096 | 7 Jul 2058 |
The rollover takes place at sunday midnight GPS time. GPS time is 19 seconds behind TAI (atomic time). The difference between UTC and TAI depends on the number of leap seconds.
A properly designed GPS receiver should not have any problems with this. If it does however, you might want to try adding the appropriate number of seconds the the NMEA time2 fudge;
| Weeks | Seconds |
|---|---|
| 1024 | 619315200 |
| 2048 | 1238630400 |
| 3072 | 1857945600 |
| 4096 | 2477260800 |
AFAIK GPSD does these corrections for you. (some versions of) NTPD may do the same.
More info in the usenet
newsgroup 'comp.protocols.time.ntp'.
If your ISP doesn't provide usenet, try
Google groups or
a free news server.