Site map  

Keeping time and related stuff

Types of time

Local time

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

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.

Formats of international time

Some sort `human readable' format;

  Sat Dec 23 14:22:04 UTC 2000


  Sat, 23 Dec 2000 14:22:04 GMT

The number of seconds since some reference point in time;

network time or internet time
The number of seconds since Mon, 1 Jan 1900 00:00:00 GMT
unix time
The number of seconds since Thu, 1 Jan 1970 00:00:00 GMT
Times prior to this date are expressed as a negative number.
`977616586' for instance is `Sun Dec 24 00:09:46 2000 GMT'.
Dos time
The number of seconds since Tue, 1 Jan 1980
Times prior to this date are expressed as a negative number.

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.

Why time is important

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!

How the various OS-es keep time

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.

CMOS Clock

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).

Keeping your computers at the correct time

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.

Misc NTPD tips

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 mask 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

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

Running your own reference clock

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 Week rollover

GPS expresses the date as a 10-bit week number. So every 1024 weeks there is a week roll-over;

0 6 Jan 1980
102422 Aug 1999
2048 7 Apr 2019
307221 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;

1024 619315200

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.


This system