Comment # 9
on bug 10440
from Jeff Morriss
(In reply to Michael Sukhar from comment #6)
> (In reply to Jeff Morriss from comment #5)
> > RFC 4330 updated the definition of the timestamp; Wireshark uses the updated
> > definition:
> >
> > ~~~
> > As the NTP timestamp format has been in use for over 20 years, it
> > is possible that it will be in use 32 years from now, when the
>
> RFC 4330 is for NTP V4. The attached log is for NTP V3. Is this change in
> Timestamp value interpretation applicable retroactively to the earlier
> versions of NTP?
Yeah, that I can't tell you. It makes some sense since NTP implementations
certainly don't care about time before 1970.
(In reply to Michael Sukhar from comment #7)
> If I read RFC 4330 above right for NTP v4 timestamp value 0 should be "6h
> 28m 16s UTC on 7 February 2036". It's not, see the attached pcap.
Well, the NTP format described in RFC 4330 also says:
There will exist a 232-picosecond interval, henceforth ignored, every
136 years when the 64-bit field will be 0, which by convention is
interpreted as an invalid or unavailable timestamp.
You are receiving this mail because:
- You are watching all bug changes.
