Time nist gov какой порт

Может кто-то работал с подобными серверами типа time.nist.gov и time.windows.com?
Как ему отправить запрос чтобы он мне вернул точное время?

автор: cheops (30.07.2007 в 10:45) письмо автору

Эти два сервиса помоему не работают, лучше пользоваться альтернативными, вроде pool.ntp.org. Возможно вас заинтересует тема по ссылке http://www.softtime.ru/forum/read.php?id_forum=1&id_theme=27051.

автор: Poison (30.07.2007 в 12:49) письмо автору

Пробывал «брать» время с time-a.timefreq.bldrdoc.gov, но он ничего не возвращает:(
Думаю что ему всетаки нужно что-то рассказать?=))

function extime ( $values = false ) <
if ( $fp = fsockopen ( «time-a.timefreq.bldrdoc.gov» , 13 , $errno , $errstr , 2 ) ) <
echo fgets ( $fp );
>
>

автор: Trianon (30.07.2007 в 13:01) письмо автору

13-й порт не имеет никакого отношения к ntp-протоколу.
Процитировааный пример — тоже.

автор: pini-pini (30.07.2007 в 13:06) письмо автору

Портокол NTP работает через UDP, а не TCP и через порт 123, а не 13

автор: Poison (30.07.2007 в 13:12) письмо автору

Побежал искать RFC=))

Почитал. только так и не понял что ему отправлять?
Trianon если вы знаете напишите пример=))

автор: Trianon (30.07.2007 в 13:28) письмо автору

Я не знаю. По описанию судя, эта штука совсем нетривиальна.

автор: cheops (31.07.2007 в 11:15) письмо автору

Дело в том, что настоящий сервер точного времени — это штука действительно не тривиальная — нужно обращаться помоему к двум серверам, время меняется не жёстко и сразу, а путём небольших коррекций в течении определённого периода (чтобы скачков не было). Лучше обращаться к текстовым сервисам вроде alpha.prao.psn.ru — получаете текстовую строку и делайте с ней что угодно.

автор: Trianon (31.07.2007 в 11:21) письмо автору

Вот с этим я совершенно не спорю.

Но предлагая такие вещи, наверное неплохо было бы помечать, что протокол всё ж таки другой? Потом же люди в процессе поиска будут сперва не понимать, что к чему, а потом — как минимум сильно удивляться.

автор: cheops (31.07.2007 в 11:09) письмо автору

Вам требуется именно этот IP-адрес использовать? Вот этот не подойдёт?

$fp = fsockopen ( «alpha.prao.psn.ru» ,
13 ,
$errno ,
$errstr ,
5 );
if (! $fp ) exit( «ERROR: $errno — $errstr » );
else echo fread ( $fp , 26 );
fclose ( $fp );
?>

автор: pini-pini (30.07.2007 в 13:04) письмо автору

Это оконное время.com — альтернативный!

автор: petersky (12.11.2007 в 23:03) письмо автору

Спасибо за альтернативную ссылку на сервис pool.ntp.org. Мне очень ромогло!

Network Time Protocol

Network Time Protocol (NTP) is a protocol that provides a very reliable way of transmitting and receiving an accurate time source over TCP/IP-based networks.

Related terms:

Synchronization
Internet Protocol
Operating Systems
Access Control List
Denial of Service Attack
Domain Name System
Global Positioning System
Transmission Control Protocol
User Datagram Protocol
Domain Controller

Add to Mendeley

About this page

Firewalls

Network Time Protocol

Network Time Protocol (NTP) is a protocol that allows the synchronization of system clocks (from desktops to servers). Having synchronized clocks is not only convenient but required for many distributed applications. Therefore the firewall policy must allow the NTP service if the time comes from an external server.

NTP is a built-on UDP, where port 123 is used for NTP server communication and NTP clients use port 1023 (for example, a desktop). Unfortunately, like many legacy protocols, NTP suffers from security issues. It is possible to spoof NTP packets, causing clocks to set to various times (an issue for certain services that run periodically). There are several cases of NTP misuse and abuse where servers are the victim of DoS attacks.

As a result, if clock synchronization is needed, it may be better to provide an internal NTP server (master clock) that synchronizes the remaining clocks in the internal network. If synchronization is needed by an NTP server in the Internet, consider using a bastion host.

URL: https://www.sciencedirect.com/science/article/pii/B9780124166882000064

The Open Systems Interconnect Model

Network Time Protocol

Network Time Protocol (NTP) is a protocol that provides a very reliable way of transmitting and receiving an accurate time source over TCP/IP-based networks. NTP, defined in Request for Comments (RFC) 1305 ( www.ietf.org/rfc/rfc1305.txt ), is useful for synchronizing the internal clock of the computers to a common time source. Some systems, such as Novell NetWare’s Novell Directory Services (NDS, or now known simply as e-Directory) as well as Microsoft Windows Server 2003 and 2000, rely on a time source to keep things running right. For system maintenance, troubleshooting of issues, and documentation, it is important that all systems be time synchronized. In addition, for prosecution of security breaches or attacks, security logs need to be accurate and so on. NTP, when used properly, can have a hierarchical disaster recovery system designed into it, with primary sources of time as well as secondaries. Having the correct time on your system(s) is very important. Many problems can surface if networked machines are not synchronized.

URL: https://www.sciencedirect.com/science/article/pii/B9781597493062000063

Case Studies

Richard John Anthony , in Systems Programming , 2016

7.3.6.2 NTP Protocol Definition Unit (PDU)

Both the NTP request message and NTP response message are encoded as fixed-size arrays of 64 bytes. The NTP PDU format overlays the linear byte array with a structure that collects the bytes into various fixed length fields and thus maps out the application meaning of the message content. Figure 7.11 shows the NTP PDU, which defines the format of NTP request and response messages.

The NTP request message is populated as follows: The entire 48-byte array is zeroed out, and then the LI, Version, and Mode fields are set to the values 3, 4, and 3, respectively; this indicates that the message is an NTP version 4 message sent from the client (i.e., a request), with a currently unsynchronized clock (i.e., the timestamp values in the message are not meaningful). See Figure 7.12 .

Figure 7.12 shows the program code that sets the NTP request message content and sends the message, in the time service client library component. Only the first byte is configured to inform the recipient that the type of message is a request (from a client) and is conformant to NTP version 4.

Figure 7.13 shows the receive method of the library component. This method is called when an NTP request message has been sent (over UDP) to the NTP time server and an NTP response is expected (also over UDP). The combined use of a short time delay and a single call to recvfrom (i.e., not repeated periodically in a loop) with the socket configured in nonblocking mode meets a useful compromise between the three potentially conflicting requirements of low-latency responsiveness, robustness, and simple design. The nonblocking socket mode ensures reliability in the sense that the call will return regardless of whether the NTP server responds or not. This is essential to prevent the NTP client library code from blocking indefinitely if the NTP server crashes or if either the request or response message is lost or corrupted in the network.

The use of the 500 ms delay allows for the round-trip time (RTT) of sending the request message and receiving the response. Network delay is continuously changing, and therefore, there can never be a perfect statically decided time-out value for long-haul network transmissions (as in the case of contacting NTP time servers). The 500 ms-delay value was found experimentally to be a good compromise between waiting long enough so that NTP responses are caught in almost all cases and on the other hand not inserting too much additional latency. Even if the RTT was near instantaneous, this approach only inserts half a second of latency.

The timestamp is held in bytes 40-47 of the response message (the Transmit Timestamp field). The timestamp value is 64 bits wide, the most significant 32 bits representing the number of seconds and the least significant 32 bits representing the fraction of seconds. For the case study application, it was deemed adequate to only consider the whole seconds part of the timestamp (hence, the values of bytes 40-43 are used as can be seen in the code in Figure 7.13 ). In applications where greater precision is needed, the fractional part of the timestamp can also be taken into account.

URL: https://www.sciencedirect.com/science/article/pii/B9780128007297000078

Improved Algorithms for Synchronizing Computer Network Clocks

Abstract

The Network Time Protocol (NTP) is widely deployed in the Internet to synchronize computer clocks to each other and to international standards via telephone modem, radio and satellite. The protocols and algorithms have evolved over more than a decade to produce the present NTP Version 3 specification and implementations. Most of the estimated deployment of 100 000 NTP servers and clients enjoy synchronization to within a few tens of milliseconds in the Internet of today.

This paper describes specific improvements developed for NTP Version 3 which have resulted in increased accuracy, stability and reliability in both local-area and wide-area networks. These include engineered refinements of several algorithms used to measure time differences between a local clock and a number of peer clocks in the network, as well as to select the best subset from among an ensemble of peer clocks and combine their differences to produce a local clock accuracy better than any in the ensemble. This paper also describes engineered refinements of the algorithms used to adjust the time and frequency of the local clock, which functions as a disciplined oscillator. The refinements provide automatic adjustment of algorithm parameters in response to prevailing network conditions, in order to minimize network traffic between clients and busy servers while maintaining the best accuracy. Finally, this paper describes certain enhancements to the Unix operating system kernel software in order to realize submillisecond accuracies with fast workstations and networks.

URL: https://www.sciencedirect.com/science/article/pii/B9781558606517501534

Distributed Systems

Richard John Anthony , in Systems Programming , 2016

6.6.1.3 Network Time Protocol (NTP)

In use since 1985, the NTP is the most popular Internet time protocol. It is based on UDP, therefore having low networking overheads and low service response latency because it does not need to establish a TCP connection.

An NTP client periodically requests updates from at least one server. When multiple servers are used, the client averages the received time values, ignoring any outlier values (in a similar way to that used by the master server in the Berkeley algorithm; see later text).

NTP provides greater precision than the TIME and DAYTIME protocols. It uses a 64-bit time stamp value representing the time in seconds since January 1, 1900, and has a resolution of 200 picoseconds (although this level of precision cannot generally be leveraged due to dynamic network delays that can fluctuate by values significantly larger than this).

The use of NTP within distributed applications has been discussed in Chapter 3 , where it is also used as an example of a request-reply protocol and explored in a practical activity using an NTP client application that has been built into the Distributed Systems Workbench.

An alternative to the continual operation of NTP is the similar but more lightweight SNTP that supports single time requests when needed (as opposed to the periodic nature of NTP usage).

Figure 6.21 illustrates infrastructural features of the NIST time service provision, showing the differentiation between the internal and external aspects of the service. The internal service configuration synchronizes the NIST internal time value to UTC/GMT and also synchronizes the NIST time servers to each other. Externally, NIST provides a number of time services that each serves the same time value but in different formats and with different levels of precision. Of these services, NTP and SNTP are the most important due to communication efficiency and precision of time values.

All of the NIST time services provide transparency to clients in the sense that clients do not need to be aware of the internal configuration and behavior of the NIST system, of the multiplicity of time services, or of the replication of NIST time servers.

URL: https://www.sciencedirect.com/science/article/pii/B9780128007297000066

Recommended publications

SSH Server Advanced Use

Maintaining System Time

Another important consideration for the SSH server is the system time. You might think that having inaccurate time is a trivial thing. Without an accurate system time, all system logs become less valuable for forensics. This is especially true when it comes to pursuing legal action. If you cannot state with certainty when an action occurred, prosecution will be that much more difficult. If you are performing centralized log collection, it will make sorting through them all that much more difficult when events on different systems cannot be correlated to a common clock.

Configuring your SSH server to use NTP ( Network Time Protocol ) to keep the system clock accurate is very easy. If NTP is not already installed, you will need to install it. On most Linux distributions, NTP comes pre-installed though it may or may not be enabled. On a Redhat-based system, you can check the run levels of installed services by entering the following:

#chkconfig –list | grep ntp

ntpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off

If ntpd is not enabled, you can enable it for runlevels 2-5 by entering:

chkconfig –level 2345 ntpd on

The NTP process can be started by entering ntpd in a terminal window. Once ntpd is enabled, it is controlled through the /etc/ntpd.conf or /etc/ntp.conf configuration file, depending on your distribution.

The configuration file needs two lines at a minimum to get things working. The following line tells NTP which server to use as a time source, in this case clock.redhat.com :

The next line will ensure that NTP will receive time from clock.redhat.com but will not allow that time server to modify your server’s configuration (nomodify) or pull time from your server (noquery):

restrict clock.redhat.com mask 255.255.255.255 nomodify notrap noquery.

You can verify that NTP is synching with the time server by running ntpq –p. Initially the time may be off by a large margin. If this is the case, you can use ntpdate timeserver> to set the time before letting ntpd manage the smaller adjustments. You may need to run ntpdate multiple times before it will adjust the time completely. This entire process is shown in Figure 12.3 .

Ntpdate will not set the time if ntpd is currently running. In order to make the large adjustments using ntpdate, stop ntpd first using service ntpd stop for example.

The most critical value for the ntpq output is the offset, which is the difference between the system clock and the referenced time source; it is expressed in milliseconds. You should configure more than one time server if possible so that ntpd can use all of them to select the best time. This also helps ensure that any single faulty time source cannot misadjust all your devices to the wrong time.

URL: https://www.sciencedirect.com/science/article/pii/B978159749283600012X

Forensic Time

Chet Hosmer , in Python Forensics , 2014

World NTP Servers

Examining the methods and properties may seem a bit confusing at first; however, using the library module is in fact quite simple. Simply put we want to create an ntp client capable of accessing a specified ntp server to obtain a third-party source of time. In the United States, NIST manages a list of time servers that can be accessed to obtain “root” time ( Figure 6.9 ).

Updated lists can be found at: http://tf.nist.gov/tf-cgi/servers.cgi .

In Europe, you can find an active list of NTP servers at the NTP Pool Project. Figure 6.10 shows a screenshot from their home page at http://www.pool.ntp.org/zone/europe .

For those of you wishing to obtain your time from the U.S. Naval Observatory or USNO, you might be interested to know that for many years, the USNO has provided access to NTP servers’ aptly named tick and tock. For more information on the U.S. Naval Observatory you can visit: http://www.usno.navy.mil/USNO .

URL: https://www.sciencedirect.com/science/article/pii/B9780124186767000062

The Communication View

Richard John Anthony , in Systems Programming , 2016

3.3.2 Request-Reply Communication

The request-reply communication mechanism is the basis of a popular yet simple group of protocols in which simple two-way communication occurs between a specific pair of processes.

A generic description of request-reply communication is as follows: Interaction begins with a request for service message, which is sent from a service requestor process to a service provider process. The service provider then performs the necessary computation and returns the result in a single message to the requestor; see Figure 3.4 .

Figure 3.4 shows the request-reply protocol concept. The essence of this strategy is that control flows to the service provider, that is, a request message, and data (the result of the request) flow back to the requestor.

A popular and easy to understand example of a request-reply protocol is the Network Time Protocol (NTP) service, which is one of several time services that constitute the Internet Time Service (ITS) provided by the National Institute of Standards and Technology (NIST), based in the United States. Synchronizing the time value of the clock on a computer to the correct real-world time is a vital prerequisite action in order that many applications function correctly. NTP provides a means of getting an accurate time value from one of a pool of specially designated NTP time servers. The synchronization among the various time servers within the ITS service itself is performed separately with its own internal hierarchical structure comprising several stratum’s (layers) of clocks, with highly accurate clocks, such as atomic clocks, in stratum 0. It is a very important point to note that external users of the NTP service do not need to know any details of this internal configuration; they simply send a request message to any one of the NTP time servers and receive a response containing the current time value. The ITS NTP service operation is illustrated in Figure 3.5 .

Figure 3.5 shows how the NTP service is accessed to retrieve a current time stamp value. In step 1, a request message formatted to comply with the NTP protocol is sent to one of the pool of NTP servers. In step 2, the specific NTP server responds with a reply message, which is sent back to the original requester (who is identified by examining the source address details in the request message). Part A of the figure provides an overview of the actual system, while part B shows the user’s simplified view of the system. This example provides some important early insights into transparency requirements for distributed systems services: the NTP client does not need to know the details of the way in which the ITS service operates internally (in terms of the number of participating NTP servers and the way in which updates and synchronization are performed among the servers) in order to use the service. In terms of behavior, the NTP time service should provide a low-latency response, further reinforcing the transparency as seen by the user. In this respect, the NTP server instance should return the instantaneously available time value from its local clock, which has been presynchronized by the NTP service itself, rather than requesting a fresh synchronization activity within the service. Figure 3.6 provides pseudocode for an NTP client.

Activity C2 explores request-reply protocols and the behavior of the Network Time Protocol (NTP) using the NTP client provided within the Distributed Systems Workbench.

Activity C2

Using the Network Time Protocol (NTP) Client Within the Distributed Systems Workbench to Explore Request-Reply Protocols and the Behavior of NTP

The US National Institute of Standards and Technology (NIST) maintains the Internet Time Service (ITS), which provides a number of well-known standard time services, one of which is the Network Time Protocol service.

Learning Outcomes

To examine the use of a request-reply protocol

To gain an initial understanding of time services

To gain an initial understanding of the Network Time Protocol

To gain an appreciation of the importance of standardization of well-known services

To gain an appreciation of the importance of a clear separation of concerns between components of a distributed application

To gain an appreciation of the importance of transparency in distributed applications

Method

Start the NTP client from the NTP tab in the Distributed Systems Workbench.

Part 1. The NTP client provides a partial list of NTP server URLs. Select each one in turn and see if they all respond with time values, and if so, do they all give the SAME time? NIST maintains a webpage at http://tf.nist.gov/tf-cgi/servers.cgi , which reports the current status of some of the NIST servers: it is not uncommon to find that one or more are unavailable at any time. This reinforces the reason why there are multiple NTP time servers available.

Part 2. NIST provides a global address: time.nist.gov , which is automatically resolved to different NIST time server addresses in a round-robin sequence to equalize the service-request load across the servers. Try selecting this URL and see what IP address it resolves to. If you make several attempts within a short time frame, then you will likely be directed to the same time server instance each time. However, if you wait several minutes between attempts, you will see that it does sequence through the available servers. Try this for yourself. Think about the importance of using this global address (especially if hard-coded into an application) rather than individual server domain names.

Expected Outcome

The first screenshot below shows the NTP client in operation, using the wolfnisttime.com NIST time server. The URL wolfnisttime.com has been resolved to IP address 207.223.123.18 and a series of NTP time requests have been sent, and responses received.

The screenshot below illustrates the use of NIST’s global address time.nist.gov . In this instance, it resolved to the server at IP address 128.138.141.172. This screenshot also reveals the unreliability of UDP; NTP requests are carried over the UDP, and you can see that while 86 requests were sent, only 84 responses were received.

The screenshot below shows how NIST’s global address time.nist.gov resolves to different NIST time server addresses at different times. In this instance, it resolved to the server at IP address 24.56.178.140.

Reflection

This activity provides some insight into the importance of a clear separation of concerns in a distributed application. In this example, the client is a bespoke program, which requests and uses the up-to-date time value from the NTP time service, which is a well-known service with publicly documented behavior and a standard interface. The client in this application has very little business logic; it is limited to resolving the URLs of the NTP service domain names into IP addresses and actually making the NTP protocol request. The rest of the client’s functionality is related to the user interface. All of the time service-related business logic is held at the NTP server side. The request-reply protocol is very well suited to this software architecture; the client sends a request and the server sends back the appropriate reply in a stateless way (i.e., the server does not need to keep track of the particular client or keep any specific context about the client’s request). This stateless approach leads to a highly scalable service, and the combination of the simple protocol and the high degree of separation of concerns means that it is very easy to develop NTP clients or to embed NTP client functionality into other applications.

The activity also illustrates some important aspects of transparency; the user does not need to know the internal structure of the ITS time services, the number of NTP server replicas or the way in which they are updated, in order to use the service. The NTP service appears to the client as a single server entity.

Further Study

The design and operation of the NTP client is explored in detail in the form of a case study in Chapter 7 .

Синхронизация времени с NTP — сервером на PHP (по протоколу DAYTIME)

Одним из первых протоколов точного времени, используемым на компьютерах, был DAYTIME (RFC 867), предназначенный для сообщения даты и времени в понятном человеку виде. Формат ответа DAYTIME строго не регламентируется и не предназначен для машинной обработки — предполагается лишь, что человеку, прочитавшему полученную строку, станет ясно текущее время.

Реализуем простую функцию для получения точного времени:

function queryTimeServer ($timeserver, $socket) < $timevalue = 0; $ret = array(); $fp = @fsockopen($timeserver,$socket,$err,$errstr,5); if ($fp) < fputs($fp,"\n"); $timevalue = fread($fp,49); fclose($fp); >$ret['time'] = $timevalue; $ret['errno'] = $err; $ret['errstr'] = $errstr; return $ret; >

Используем, например, так:

// По умолчанию берем время с нашего сервера $timevalue = time(); // Если запрос к NTP успешен - берем время из него $timercvd = queryTimeServer("pool.ntp.org", 13); if (!$timercvd['errno'] && $timercvd['time'] > 0) < $timevalue = strtotime($timercvd[0]); >echo "Точное время: ";

Для получения точного времени помимо pool.ntp.org также можно использовать следующие сервера:

time.windows.com
time.nist.gov
time-a.nist.gov
time-b.nist.gov
time-a.timefreq.bldrdoc.gov
time-b.timefreq.bldrdoc.gov
time-c.timefreq.bldrdoc.gov

Не следует путать daytime protocol RFC 867 с NTP или time protocol RFC 868

Ссылки

Протокол NTP
Список портов TCP и UDP

Internet Time Service Firewall information

A firewall is a device that can protect your computer by selectively blocking connections from the Internet. A firewall can be built using hardware, software, or a combination of the two, and some operating systems (such as Windows and Linux) contain firewall software as part of the operating system itself.

There are a number of points to consider if you have any type of firewall and are planning to use it with the NIST Internet Time service. You must understand a bit about how computers communicate over the Internet in order to be able to configure your firewall properly.

There are 4 parameters that specify how a client program communicates with a remote server. The first is the server address, which can be specified using a name, such as time-a.nist.gov or using a series of numbers, such as 129.6.15.28. Both of these specifications are equivalent, although the numerical form is what is actually used by the system — the name is converted to the numerical form automatically. In general, the name is more convenient to use, but the numerical form requires less overhead to process and is generally preferred if you are going to make many requests to the same server.

The second parameter is the protocol, which specifies the format of the messages that are exchanged. The NIST servers support two common protocols: tcp, the transmission control protocol, and udp, the user datagram protocol. Finally, the third and fourth parameters are the port numbers on the client and the server. The server port number specifies which program on the NIST server will actually receive and process your request and the client port number specifies which program on your system will initiate the request and handle the response.

The port number on your system is arbitrary, and is usually chosen at random by your system each time the client program prepares to make a request for the time. Therefore, it is likely to vary from one request to another. However, the NIST time servers will only listen for and respond to requests addressed to a few specific port numbers and protocols. These combinations are:

udp port 123, which is used by the network time protocol and the simple network time protocol. The NIST client software (and software from other sources) can be configured to use this port, but often does not use it by default. The NIST servers listen only on this port for NTP requests.
tcp port 13, which is used by the NIST client software by default and by other programs that use the «daytime» protocol. This NIST servers listen only on this port for “daytime” requests.
tcp port 37 and udp port 37, which are used by DATE, RDATE, SDATE and by other programs that use the «time» protocol. The NIST servers listen ony on these ports for requests in the “time” format.

In order to successfully access the NIST time servers, your firewall must allow outbound connections via the remote port and protocol combination that you will be using. The port number on your system will probably vary from one request to another, and you will probably have to allow messages from any port number on your system to pass through the firewall if it is addressed to one of the specific ports on the NIST system, and to allow messages addressed to any port on your system to go through the firewall if it is coming back from one of these specific time service ports.

It is generally easier to configure a firewall when your client uses the TCP-based daytime format, since TCP communication implicitly associates a response from our time server with the request that solicited it, and the firewall is less likely to block a response to a request that originated from the local system. (The NISTIME client software uses this communication format by default.) However, this is not always true, and it is sometimes easier to use the UDP-based Network Time Protocol (NTP) format. Since this format is very widely used, many firewalls will pass messages in this format by default. However, some firewalls will not associate a reply in UDP format to the query that solicited it, and may block the reply unless the firewall is explicitly configured to pass UDP messages in both directions to and from a time server and the client system.

The NISTIME client software can use either of these formats, and you should try the NTP format if the firewall will not pass the TCP-based messages that are used by default. The choice between the two formats is made using the File | Select Server menu. Each server on the list can be configured to be queried in either format. After you have configured the servers, you should save the configuration using File | Save Config, so that you don’t have to select these options when you run the program again.

If these connections are blocked, the program will not receive a response to a time request and will usually report an error. In addition, some firewalls will not associate the response from the server with the message that requested it, and will treat the response as an unsolicited «attack.» You should consider this possibility if you see many «attacks» that seem to originate from one of the time service ports listed above. Finally, many DATE, RDATE and SDATE programs have poor error handling capabilities, and may set the time on your system to a strange value (often in the year 2036) if the response is blocked or garbled. We do not recommend any of these programs for this reason.

For questions or more information about the NIST Internet Time Service, contact jlevine [at] boulder.nist.gov (Judah Levine) .

Time nist gov какой порт