On 02/07/2013 12:24 PM, John Stultz wrote:On Thu, Feb 7, 2013 at 5:29 AM, Prarit Bhargava <prarit@xxxxxxxxxx> wrote:I'm not sure I understand the purpose behind the +/-15 minute window? Is itWe do not see this manifest on some architectures because they limit changesInteresting.
to the rtc to +/-15 minutes of the current value of the rtc (x86, alpha,
mn10300). Other arches do nothing (cris, mips, sh), and only a few seem to
show this problem (power, sparc). I can reproduce this reliably on powerpc
with the latest Fedoras (17, 18, rawhide), as well as an Ubuntu powerpc spin.
I can also reproduce it "older" OSes such as RHEL6.
Yea, local RTC time is probably pretty rare outside of x86 (due to windows).
And the +/- 15minute trick has always explicitly masked this issue there.
just to prevent a wild swing on the RTC? I can understand that to some degree,
however, I'm not sure I agree with it being the default behaviour.
Here's a real-world scenario:
My RTC on my laptop is set to 1:30PM Jan 7, 2013. I boot, systemd and ntp do
their magic, and the system time comes up as Feb 7, 12:48PM. I never will
notice that the RTC is wrong.
Now I go somewhere and have to work on a plane. I have no internet connection
and then boot. Now the system time will be 1:30PM Jan 7, 2013. That's actually
happened to me and I remember filing it away for a bug to be looked at.
AFAIK, no other OS does that ... if I install Windows or use a Mac in the
no-internet connection case, the time is *always* corrected. I tried to see if
I could get this to happen on a Mac and I can't.
99.99999% of Linux users out there are using some sort of time protocol (usually
NTP, but PTP is starting to catch on) to sync their systems. NTP is a trusted
source of timekeeping IMO. How often do we see systems that run NTP but don't
trust the numbers that come from it?
sys_tz can be set during runtime via settimeofday() without affecting the/*So why is this extra flag necessary instead of just using if
+ * Indicates if there is an offset between the system clock and the hardware
+ * clock/persistent clock/rtc.
+ */
+int sys_time_offset;
(sys_tz.tz_minuteswest) ?
current system time. The bug *only* happens if the system clock is "warped"
ahead relative to the hardware clock on the first call to settimeofday(), so
checking for sys_tz.tz_minuteswest isn't good enough of a test.