Domain Time II operates under the assumption that there exists one true time,
Coordinated Universal Time or UTC. The goal of clock
synchronization, then, is for each machine to discover the UTC and make sure its clock matches.
Local time is derived from UTC independently by each machine, by applying time zone and daylight
savings corrections specified on that machine. Local time is meaningful only to
that particular machine (or others that happen to share its exact assumptions about time
zones and daylight savings time), so is never used when communicating time among
machines. Regardless of the protocol used between machines, Domain Time II always uses
UTC to communicate the time. This allows Domain Time II to operate among machines in
any time zone, regardless of local daylight savings time. (See Note below.)
Since it is not practical for each machine to have direct access to a precise source
such as a cesium clock or GPS clock, Domain Time II machines rely instead on trusted sources to
provide the time. A trusted source is another computer that has obtained the UTC
in a reliable fashion and is willing to share that information. Domain Time includes tools to
help you determine if your trusted source is reliable - see the DT Test Utility.
By default, a Domain Time II server will not serve the time to other machines until it has
set its own clock at least once from a trusted source. Some protocols, such as NTP,
include a bit flag in the server's response to indicate whether or not the server's
clock is synchronized. Other protocols rely on the use of a known invalid time to
indicate an unsynchronized server. In addition to these safety checks, Domain Time II
also insists that the received time be "reasonable" -- that is, that it falls within
the range of acceptable dates based on a number of specific criteria (see the
Clock Target Seeking page for more information.
A Domain Time II client (including servers that get their time from other servers)
will not accept an invalid time.
In addition to the above considerations, the physical nature and software limitations
of computer clocks and network communications introduce cumulative errors into the process
of sending and receiving the correct time. It is vital that these factors be identified
and compensated for on every machine involved in the time chain to achieve a reliable
approximation of the "true time" on any system.
Domain Time II addresses these issues in multiple ways:
- It uses sophisticated clock adjustment algorithms to increase the stability of each computer clock
- It uses multiple network latency discovery and correction methods to deal with the vagaries of network traffic.
- The user may opt to use the Domain Time II time protocol specification, which has enhanced server
to client communications to increase time accuracy, and additional network latency compensation features.
- Domain Time II uses special communications between Master and Slave Time Servers to maximize accuracy and minimize
any variances introduced in the upper levels of the time chain which can create a time error "domino" effect when
propagating time to the clients.
- It compensates for the various time resolution limitations inherent in the operating system, achieving the maximum
available accuracy for each system.
- It uses an efficient time distribution hierarchy and triggered time cascades to rapidly distribute server time
changes throughout the network to avoid mis-matched times between the top-level servers and clients who may have
otherwise been on a leisurely update schedule and not checked their time for a long period.
As you can see, each of these items is critical in obtaining and maintaining the "One True Time."
See the Accuracy pages of the documentation for a complete discussion of these topics.
Domain Time II does not use UTC when communicating with the special Windows for Workgroups
client. This is because Windows for Workgroups does not support time zones and daylight
savings corrections automatically. In this one special case, the WfWG client receives
the server's local time. Since the WfWG client operates using mailslots (which only
operate over the local segment), it is reasonable to assume that the server's local
time and the WfWG client's local time should match. The server makes this special local time mode of
the Domain Time II I protocol available only to WfWG machines, and WfWG machines are never
time servers themselves, so there is no possibility of time zone contamination propagating
beyond the WfWG client.