In general, a time-travel sanity check at bootup is wise to handle when the RTC clock battery fails or is just installed (i.e. if the hardware jumps decades back into the past, than the local NTP/DNS/DHCP service is briefly paused while an abnormally large leap-forwards is forced from the time configuration commands. During this process, both client and server side SSL will usually be dropped due to the abnormality.)
Rookie mistake, like not using UTC time on the servers. =)
If your clock was just reset, how do you know what time it is? How do you trust that your own clock is accurate? How do you know your clock wasn't incorrect before? Usually the answer to all these is NTP.
The epoch "zero time" on most hardware RTC is decades in the past.
Thus, it is generally a safe assumption to check if the system release date is in the future. One often doesn't want to trip this fix every boot as it can have collateral consequences in poorly written software.
We have a no time-travelers policy in most situations, and recommend others try to also constrain transactional-validity temporal-windows. Some hardware fakes an RTC by writing the current time to a cache file on disk on power cycles, but it would take a hour to explain why this is unwise (even if using GPS stratum time). =)
Comments
In general, a time-travel sanity check at bootup is wise to handle when the RTC clock battery fails or is just installed (i.e. if the hardware jumps decades back into the past, than the local NTP/DNS/DHCP service is briefly paused while an abnormally large leap-forwards is forced from the time configuration commands. During this process, both client and server side SSL will usually be dropped due to the abnormality.)
Rookie mistake, like not using UTC time on the servers. =)
If your clock was just reset, how do you know what time it is? How do you trust that your own clock is accurate? How do you know your clock wasn't incorrect before? Usually the answer to all these is NTP.
The epoch "zero time" on most hardware RTC is decades in the past.
Thus, it is generally a safe assumption to check if the system release date is in the future. One often doesn't want to trip this fix every boot as it can have collateral consequences in poorly written software.
We have a no time-travelers policy in most situations, and recommend others try to also constrain transactional-validity temporal-windows. Some hardware fakes an RTC by writing the current time to a cache file on disk on power cycles, but it would take a hour to explain why this is unwise (even if using GPS stratum time). =)