NTP Y2038 & Y2036

Question

Hi,

I am currently investigating the implications of the year 2036 and 2038 rollover bugs for a particular project. The software implemented by this project must be capable of running beyond these two dates.

My initial research shows that the NTP timestamp rollover in 2036 is actually non-issues as the protocol holds up.

My current problem is related to the 2038 rollover condition if an NTP client running on a 64-bit OS is being synchronized to an NTP server running on a 32-bit OS. Does anyone know if under this circumstance, the 64bit system will be incorrectly synchronized? Keeping in mind that the NTP protocol uses modulo arithmetic and relative NTP timestamps to calculate synchronization offsets.

Answer 1

First, it's unlikely any 32-bit machines will be sold outside the embedded space as of even next year, meaning that such machines would be over a quarter of a century old at the time (unlikely, but not unheard of).

Second, the better 32-bit OS' have already switched, partially or fully, to 64-bit for time purposes, or even just an additional flag field to handle the epoch's. So the OS running would be similarly old, which is unlikely.

Third, it's likely the NTP server (remember NTP timestamps are not just the OS timestamp) on such a broken machine would handle this.

Fourth, if it didn't you probably couldn't sync to it, and if it did you wouldn't want to.