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.

Note:
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.