Top of Page

 Documentation\Technical\Network\Time Protocols
    A protocol is an agreed-upon way to exchange data. Domain Time II (the program) uses many different protocols -- including Domain Time II (the protocol) -- to discover the time of day when talking to other machines. Most of these protocols rely on TCP/IP for their underlying transport connectivity.

    Note that regardless of the accuracy of the underlying protocol, the operating system may not be able to utilize the full precision when setting the time. For example, Win95/Win98 machines can only set the time to the next-higher 55-millisecond interval (an 1/18 of a second).

    DT2 (UDP & TCP)
    Resolution:  1 hectonanosecond
    Accuracy:  Less than 1 millisecond best-case, 1-10 milliseconds via Internet
    Port:  9909 UDP / 9909 TCP (registered with IANA as "domaintime")
    Dates:  01 Jan 1900 through 31 Dec 21244
    Server:  Supported
    Client:  Supported
    Desc:  DT2 is an open protocol used by version 2.x or above of Domain Time II (both client and server). Its theoretical limit of accuracy is one ten-tenth of a microsecond (0.0000001 seconds, also known as 1 hectonanosecond), but in practice DT2 is limited to a best-case accuracy of 0.5 to 1 millisecond, like any other network time protocol, due to asymmetries of network traffic. Domain Time II typically achieves accuracies under 10 milliseconds regardless of the distance between machines or type of connection.

    In addition to supporting the communication of time among machines, DT2 is a full-featured, extensible, multi-tiered specification allowing control messages, statistics exchange, and multiple data formats. Unlike NTP/SNTP, whose data format requires complex floating-point calculations with their attendant rounding errors, the DT2 protocol allows implementations to convert among useful time representations using only integer math.

    DT2 over HTTP
    Resolution:  1 hectonanosecond
    Accuracy:  1-100 milliseconds typical
    Port:  80 TCP (can use any port)
    Dates:  01 Jan 1900 through 31 Dec 21244
    Server:  Supported
    Client:  Supported
    Desc:  A Domain Time II Server can be configured to answer on port 80, just like a web server. If visited by a browser, the server will display a normal HTML page, including the version of Domain Time II and the local time on the server. For an example, you may visit

    The Domain Time II Server examines the request headers to determine if the request is coming from a browser or a client machine trying to set its clock. If the request is from a client, Domain Time II Server responds with a specially encoded set of headers and abbreviated body that the client can use to calculate UTC. The server also provides packet serialization and sequence numbers so the client can distinguish between timely responses and cached information. If the server's own clock is not set, it will return an HTTP "503 Not Synchronized" message to the client; otherwise it returns the standard "200 OK" message.

    If the client does not have direct access to the server's port 80, the client may be configured to use a regular web proxy server. Domain Time II Server uses expiry headers and no-cache directives to keep the proxy server from caching the response; however, Domain Time II has no control over proxy servers that are non-compliant. The client examines the serialization information to ensure that the response came directly from the Domain Time II server rather than the proxy's cache.

    Domain Time II supports proxy authentication. If your proxy server requires authentication, you may specify a username and password on the proxy line: user:pass@proxyname

    For example, if the proxy server is, a valid username is bubba with password gump, you would use as the proxy server string.

    You may also specify the proxy port number on the proxy string. If the parameter is omitted, the default port used is 80.

    Domain Time II supports SOCKS4 as well as regular web proxies. If your connection to the Internet is through a SOCKS4 gateway/firewall, then append /socks4 after the proxy server name. Example:

    The HTTP protocol has a high overhead, and the calculation's accuracy therefore suffers, but DT2 over HTTP is about as accurate as NTP/SNTP across a WAN, and useful in situations where access to ports other than 80 have been blocked by a firewall.

    RFC:  RFC 1769 RFC 2030
    Resolution:  1 microsecond in practice, 200 picoseconds in theory
    Accuracy:  1-50 milliseconds on a LAN, 50-250 milliseconds via Internet
    Port:  123 UDP
    Dates:  01 Jan 1970 through 31 Dec 2035 or beyond (implementation-dependent)
    Server:  Supported
    Client:  Supported
    Desc:  The (Simple) Network Time Protocol's theoretical accuracy is on the order of a picoseconds, but this level of accuracy is far below the granularity of all PC clocks and much laboratory test equipment. In practice is NTP is limited a few milliseconds (thousandths of a second) in a symmetric multi-peer implementation. SNTP, a simplified version of the full NTP specification suitable for PC clocks set over the network, typically achieves accuracies of 1-250 milliseconds. Domain Time is a fully-compliant SNTP server and client.

    When acting as an SNTP server, Domain Time II represents itself as stratum 2 if it is a master, stratum 3 if it is a slave, or stratum 4 if it is an independent time server. Domain Time II sets the outbound ReferenceID field to GREY if the time source was not another NTP server.

    Domain Time I
    Resolution:  1 millisecond
    Accuracy:  1 millisecond best case, 10-50 milliseconds typical (only LANs supported)
    Port:  N/A (uses mailslots; works with TCP/IP, IPX/SPX, or NetBEUI, as long as the server and client are running at least one of the same protocols)
    Dates:  01 Jan 1900 through 31 Dec 21244
    Server:  Supported
    Client:  Supported
    Desc:  Domain Time I is a proprietary protocol used by version 1.x of the Domain Time Client to obtain the time from a Domain Time Server. Domain Time I uses mailslots to deliver a host-byte-ordered representation of a Microsoft SYSTEMTIME structure. The theoretical accuracy of this protocol is one millisecond. A version 1.x Domain Time Client will attempt to discover the nearest BDC and direct a mailslot query to that machine. If the BDC's name cannot be determined, or if the targeted machine fails to respond (perhaps because it is not running the Domain Time server program), the Domain Time Client resorts to a broadcast query, and accepts the time from the first responding server. Mailslot broadcasts do not cross IP subnets. The Domain Time I protocol is supported by Domain Time 1x and Domain Time II Server version 2.x or above, but is depreciated in favor of the Domain Time II protocol.

    Domain Time I also supports the Domain Time Client for Windows for Workgroups. In a special mode specifically for this client, the Domain Time I protocol provides the server's local time instead of UTC/GMT. This is because Windows for Workgroups does not support timezones and daylight savings time adjustments. Since the Domain Time Client for Windows for Workgroups only works on the local segment, it is reasonable to assume that the client machine's time zone and daylight savings settings should match the local server's settings. Note that this particular combination -- Domain Time Client for Windows for Workgroups using Domain Time I against a Domain Time II server -- is the only time the server's time zone settings matter to a client. All other protocol-client combinations use UTC/GMT.

    LAN Manager
    Resolution:  10-15 milliseconds
    RFC:  NetRemoteTOD
    Accuracy:  10 milliseconds best case, 100-500 milliseconds typical
    Port:  N/A
    Dates:  01 Jan 1900 through 31 Dec 21244
    Server:  Supported
    Client:  Supported on NT and Windows 2000
    Desc:  NetRemoteTOD is a protocol built into Windows NT. The theoretical accuracy is one hundredth of a second, but this protocol does not provide for measuring network latency, so can be wildly off when used over a WAN or unreliable network. The chief advantage of NetRemoteTOD is that is does not require TCP/IP; it will operate over whatever transport is available, including NetBEUI, IPX/SPX, and TCP/IP. If used with TCP/IP, NetBIOS over TCP/IP (NetBt) is required.

    Version 1.x of Domain Time used NetRemoteTOD in conjunction with its own latency measurements to coordinate the time among NT machines. The protocol is still supported for backward compatibility and for those situations where no TCP/IP connectivity is available between server and client. It is not otherwise used by Domain Time II version 2.x or above.

    RFC:  RFC 868
    Resolution:  1 second
    Accuracy:  0.5 seconds best case, 1.0-1.5 seconds typical
    Port:  37 TCP, 37 UDP
    Dates:  01 Jan 1970 through 31 Dec 2035
    Server:  Supported
    Client:  Supported
    Desc:  Called either "Time Protocol" or "Internet Time Protocol" (and sometimes also "RDATE" because of the rdate program that uses this protocol), TIME's granularity is one second, so is useful primarily only when other protocols are not available. Domain Time II supports both client and server sides for TIME/ITP over both TCP and UDP.

    RFC:  RFC 867
    Resolution:  unmeasurable
    Accuracy:  unmeasurable
    Port:  13
    Server:  Not supported
    Client:  Not supported
    Desc:  Not used by Domain Time II server or client. This protocol relies on expressing the time of day as a text string, without a format specification. This makes Daytime useful for humans, but not for computers.

    Note: Domain Time II Server will serve time via the Daytime protocol, but no Domain Time II component uses Daytime for time synchronization purposes. Domain Time II Server's Daytime string format defaults to the NIST standard (see below), but may be customized to any format.

    NIST Daytime Protocol
    Resolution:  1 second; using estimation of lag time, 100-250 milliseconds are theoretically possible
    Accuracy:  100-250 milliseconds best case; 1-2 seconds typical
    Port:  13
    Server:  Not supported
    Client:  Not supported
    Desc:  The NIST Daytime Protocol is not used by Domain Time II server or client. NIST Daytime uses a variation of the Daytime protocol (see above) with a defined text string response from the server. Although this overcomes the parsing problems of the standard Daytime protocol, the NIST Daytime protocol is limited in accuracy to one second. Repeated testing to estimate round-trip time, plus text parsing, can yield (undependably) sub-second accuracy.

    Note: Most servers operated by NIST also provide the time via NTP and TIME as well as NIST's version of Daytime. You may still use NIST as your time source with the other, higher-accuracy, protocols.

Domain Time II Software distributed by Microsemi, Inc.
Documentation copyright © 1995-2024 Greyware Automation Products, Inc.
All Rights Reserved
All Trademarks mentioned are the properties of their respective owners.