The use of the ICMP Timestamps is optional, and may, or may not, be implemented. You may find many hosts or network devices do not implement this option. RFC 1812 explains that NTP is a better option to synchronize clocks.
RFC 1122, Requirements for Internet Hosts -- Communication Layers
(e) Timestamp Option
Implementation of originating and processing the Timestamp option is
OPTIONAL. If it is implemented, the following rules apply:
- The originating host MUST record a timestamp in a Timestamp option whose Internet address fields are not pre-specified or whose first
pre-specified address is the host's interface address.
- The destination host MUST (if possible) add the current timestamp to a Timestamp option before passing the option to the transport
layer or to ICMP for processing.
- A timestamp value MUST follow the rules given in Section 220.127.116.11 for the ICMP Timestamp message.
18.104.22.168 Timestamp and Timestamp Reply: RFC-792
A host MAY implement Timestamp and Timestamp Reply. If they are
implemented, the following rules MUST be followed.
The ICMP Timestamp server function returns a Timestamp Reply to every
Timestamp message that is received. If this function is implemented,
it SHOULD be designed for minimum variability in delay (e.g.,
implemented in the kernel to avoid delay in scheduling a user
The following cases for Timestamp are to be handled according to the
corresponding rules for ICMP Echo:
- An ICMP Timestamp Request message to an IP broadcast or IP multicast address MAY be silently discarded.
The IP source address in an ICMP Timestamp Reply MUST be the same as
the specific-destination address of the corresponding Timestamp
- If a Source-route option is received in an ICMP Echo Request, the return route MUST be reversed and used as a Source Route option for
the Timestamp Reply message.
- If a Record Route and/or Timestamp option is received in a Timestamp Request, this (these) option(s) SHOULD be updated to
include the current host and included in the IP header of the
Timestamp Reply message.
- Incoming Timestamp Reply messages MUST be passed up to the ICMP user interface.
The preferred form for a timestamp value (the "standard value") is in
units of milliseconds since midnight Universal Time. However, it may
be difficult to provide this value with millisecond resolution. For
example, many systems use clocks that update only at line frequency,
50 or 60 times per second. Therefore, some latitude is allowed in a
(a) A "standard value" MUST be updated at least 15 times
per second (i.e., at most the six low-order bits of the
value may be undefined).
(b) The accuracy of a "standard value" MUST approximate
that of operator-set CPU clocks, i.e., correct within a
RFC 1812, Requirements for IP Version 4 Routers
(e) Timestamp Option
Routers MAY support the timestamp option in datagrams originated by
the router. The following rules apply:
o When originating a datagram containing a Timestamp Option, a router
MUST record a timestamp in the option if
- Its Internet address fields are not pre-specified or
- Its first pre-specified address is the IP address of the
logical interface over which the datagram is being sent
(or the router's router-id if the datagram is being sent
over an unnumbered interface).
o If the router itself receives a datagram containing a Timestamp
Option, the router MUST insert the current time into the Timestamp
Option (if there is space in the option to do so) before passing the
option to the transport layer or to ICMP for processing. If space is
not present, the router MUST increment the Overflow Count in the
o A timestamp value MUST follow the rules defined in [INTRO:2].
To maximize the utility of the timestamps contained in the timestamp
option, the timestamp inserted should be, as nearly as practical, the
time at which the packet arrived at the router. For datagrams
originated by the router, the timestamp inserted should be, as nearly
as practical, the time at which the datagram was passed to the Link
Layer for transmission.
The timestamp option permits the use of a non-standard time clock, but
the use of a non-synchronized clock limits the utility of the time
stamp. Therefore, routers are well advised to implement the Network
Time Protocol for the purpose of synchronizing their clocks.
You can write your own application to use timestamps (assuming your devices support this option). Otherwise, product or resource recommendations are off-topic here.