And it is saying that the timestamp format of 64bits is:
Expand|Select|Wrap|Line Numbers
- . 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Seconds |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Seconds Fraction (0-padded) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
That seems all well and good. BUT I am sending a request to a NIST server and getting back what should be correct responses. However their seconds values don't seem to match up:
Here is some sample output:
Expand|Select|Wrap|Line Numbers
- Should get roughly(in some order): 50 EC 25 21 00 00 00 00
- (UDP RETURN LENGTH: 48 Bytes)
- LI: no warning
- VN: 4
- MODE: server
- STRATUM: primary reference (e.g., synchronized by radio clock)
- POLL INTERVAL: 2^(0) = 1
- PRECISION: 2^(226) = -9223372036854775808
- ROOTDELAY: 0
- ROOTDISPERSION: 0
- REFERENCEID: ACTS
- //This would be the timestamps, given in-order as HEX bytes
- //So the first 4 HEX bytes should be similar to my guessed value above
- Reference TimeStamp: CA 6F 40 8D 4F 4C 68 B0
- Originate TimeStamp: 00 00 00 00 00 00 00 00
- Receive TimeStamp: CA 6F 40 93 B7 DC C1 C8
- Transmit TimeStamp: CA 6F 40 93 B7 DD CC F1
As you can see:
CA 6F 40 xx varies by a total of 6 seconds...but none of those values, as seconds, comes anywhere near the current date and time (I'm talking off by many years, not just minutes or so)
Does anyone know a good way to interpret the 64Bit TimeStamp? This seems silly that it doesn't work out nicely.