Hide Forgot
Description of problem: ntpdate, when ran at time after ((uint32_t) -1) sets the date even further to the future. Version-Release number of selected component (if applicable): ntpdate-4.2.6p5-11.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. set date to (uint32_t) -1 (Feb 7 2106 appx.) 2. run ntpdate ${SERVER_OF_CHOICE} # i used clock.redhat.com 3. note that time 0x100000000 has passed between the commands Actual results: The current time is set to something around the year 2150 Expected results: The current time is set to the actual current time Additional info: Tested only on x86_64 architecture. Not sure if it relates to times < UINT_MAX Also, setting the time to RTC fails (at least on my machine).
This happens because year 2106 is in the next NTP epoch and ntpd/ntpdate assumes the system clock is in the correct epoch (the NTP time stamps use 32 bits and the current epoch starts in 1900). However, this problem is addressed in the current ntp-dev versions which will be followed by a stable 4.2.8 release. The time of the build is used as a reference when converting the NTP time stamp to the system time and it should step the clock correctly even when the initial time is another NTP epoch. As this is already fixed upstream and we are just waiting for the stable release, I'm closing this report.