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 3.2.2.8 for the ICMP Timestamp message.
3.2.2.8 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 process).
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 Request message.
- 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 "standard value":
(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 few minutes.
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 option.
o A timestamp value MUST follow the rules defined in [INTRO:2].
IMPLEMENTATION
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.