I C M P时间戳请求允许系统向另一个系统查询当前的时间。返回的建议值是自午夜开始计算的毫秒数，协调的统一时间（ Coordinated Universal Time, UTC）（早期的参考手册认为U T C是格林尼治时间）。这种I C M P报文的好处是它提供了毫秒级的分辨率，而利用其他方法从别的主机获取的时间（如某些U n i x系统提供的r d a t e命令）只能提供秒级的分辨率。由于返回的时间是从午夜开始计算的，因此调用者必须通过其他方法获知当时的日期，这是它的一个缺陷。
I C M P时间戳请求和应答报文格式如图6 - 6所示。

请求端填写发起时间戳，然后发送报文。应答系统收到请求报文时填写接收时间戳，在发送应答时填写发送时间戳。但是，实际上，大多数的实现把后面两个字段都设成相同的值（提供三个字段的原因是可以让发送方分别计算发送请求的时间和发送应答的时间）。
6.4.1 举例
我们可以写一个简单程序（取名为i c m p t i m e），给某个主机发送I C M P时间戳请求，并打印出返回的应答。它在我们的小互联网上运行结果如下：

程序打印出I C M P报文中的三个时间戳：发起时间戳（ o r i g）、接收时间戳（ r e c v）以及发送时间戳（ x m i t）。正如我们在这个例子以及下面的例子中所看到的那样，所有的主机把接收时间戳和发送时间戳都设成相同的值。
我们还能计算出往返时间（r t t），它的值是收到应答时的时间值减去发送请求时的时间值。d i f f e r e n c e的值是接收时间戳值减去发起时间戳值。这些值之间的关系如图6 - 7所示。

如果我们相信RT T的值，并且相信RT T的一半用于请求报文的传输，另一半用于应答报文的传输，那么为了使本机时钟与查询主机的时钟一致，本机时钟需要进行调整，调整值是d i f f e r e n c e减去RT T的一半。在前面的例子中， b s d i的时钟比s u n的时钟要慢7 ms和8 ms。
由于时间戳的值是自午夜开始计算的毫秒数，即U T C，因此它们的值始终小于86 400 000 ( 2 4×6 0×6 0×1 0 0 0 )。这些例子都是在下午4 : 0 0以前运行的，并且在一个比U T C慢7个小时的时区，因此它们的值比82 800 000（2 3 0 0小时）要大是有道理的。
如果对主机b s d i重复运行该程序数次，我们发现接收时间戳和发送时间戳的最后一位数总是0。这是因为该版本的软件（ 0 . 9 . 4版）只能提供1 0 m s的时间分辨率（说明参见附录B）。
如果对主机s v r 4运行该程序两次，我们发现S V R 4时间戳的最后三位数始终为0：

由于某种原因， S V R 4在I C M P时间戳中不提供毫秒级的分辨率。这样，对秒以下的时间差调整将不起任何作用。
如果我们对子网1 4 0 . 2 5 2 . 1上的其他主机运行该程序，结果表明其中一台主机的时钟与s u n相差3 . 7秒，而另一个主机时钟相差近7 5秒：

另一个令人感兴趣的例子是路由器g a t e w a y（一个C i s c o路由器）。它表明，当系统返回一个非标准时间戳值时（不是自午夜开始计算的毫秒数， U T C），它就用32 bit时间戳中的高位来表示。我们的程序证明了一点，在尖括号中打印出了接收和发送的时间戳值（在关闭高位之后）。另外，不能计算发起时间戳和接收时间戳之间的时间差，因为它们的单位不一致。

如果我们在这台主机上运行该程序数次，会发现时间戳值显然具有毫秒级的分辨率，而且是从某个起始点开始计算的毫秒数，但是起始点并不是午夜U T C（例如，可能是从路由器引导时开始计数的毫秒数）。
作为最后一个例子，我们来比较s u n主机和另一个已知是准确的系统时钟—一个N T P satum 1服务器（下面我们会更多地讨论N T P，网络时间协议）。

如果我们把d i f f e r e n c e的值减去RT T的一半，结果表明s u n主机上的时钟要快3 8 . 5～51.5 ms。
6.4.2 另一种方法