I read about the 2036 problem of NTP and i decided to make some tests on it. My server takes the time from his local clock, and my client takes the time only from this server (not even his local clock).
I changed the server date to 01 JAN 2040 12:00:00 and the client was polling the server and changed his date to 2040. I am running NTP Version 4 on the client, did this problem got patched ? If yes, was it in Version 4 or earlier ?
After that, i decided to change the server date to year 2070. Now the client is ignoring the server, it can see it, the poll reached 377, more than 5 minutes has passed, but it never synchronizes to it. It seems like he his ignoring it because of a wrong date.
Do you know the maximum date a server can broadcast before client ignoring it ?
I'm simplifying quite a bit, so those interested in getting into the weeds should read the relevant RFCs, other documentation and web pages on the subject.
NTP won't sync correctly to a source that is more than approximately 68 years out of sync. NTP uses a 64-bit timestamp, the zero value of which is January 1, 1900, but on the wire protocol this is truncated to 32 bits. The high 32 bits, not sent over the network, is the NTP era, a time of about 136 years. NTP era 0 runs from January 1, 1900, to February 7, 2036, when the 32-bit value rolls over from 4294967295 to 0 and NTP era 1 begins. Because the NTP era isn't sent over the wire, NTP clients will assume that the source should be within 2147483648 seconds (about 68 years) of its own clock. If the difference is more than 68 years, the client will either set the wrong time or refuse to sync.
This is unlikely to be a practical problem in 2036 when the NTP era rolls over, as most systems will already have clocks set to a value within 68 years, but it may be a rather larger problem in 2038 when 32-bit UNIX-based operating systems' clocks roll over from 2038 to 1901. Not only will they no longer sync to NTP, they'll spark Y2K-style chaos when whatever applications they run misbehave due to the invalid date.
Eventually your client with a 49 year wrong date should sync, though if the NTP client only slews, you and everyone you know will be long dead before it happens. Nobody wants to wait 98,000 years to sync their clock, which is why large differences are stepped instead. Note that if the clock is far out of sync, ntpd may wait as much as 15 minutes before stepping it. You said you only waited five minutes. There might also be other things going on in the NTP client or in the OS that aren't very interesting, since as a practical matter we'll just set the clock manually and get on with our day.