| Summary: | ntpdate makes wrong date even worse when after year 2106 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Bříza <mbriza> |
| Component: | ntp | Assignee: | Miroslav Lichvar <mlichvar> |
| Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 19 | CC: | mlichvar, pertusus |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-12-02 17:29:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
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. |
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).