Does Fedora mess up the clock for Windows?

[Matthew Saltzman]

On Fri, 26 May 2006, Mikkel L. Ellertson wrote:

> Leon wrote:
>> "Lee Maschmeyer" <lee_maschmeyer at wayne.edu> writes:
>>
>>> Hi all,
>>>
>>> I have a dual boot system with FC5 and Windows XP. On FC5 I run ntpd
>>> with the default config files. The drift file varies widely, from -0.4
>>> or so to as much as -60 or 100 or more. Generally the longer Fedora is
>>> up the smaller the number, though it's always negative.
>>>
>>> But Windows is losing time hand over fist, maybe a couple minutes or
>>> more in a 3-hour Windows session. I use an old program (AtomTime95) to
>>> correct the Windows clock periodically but it doesn't do any permanent
>>> good.
>>>
>>> I had the same kind of thing happen with Fedora 4. It went away when I
>>> installed Fedora 5 until I activated ntpd.
>>>
>>> According to /var/log/messages Fedora has to set the clock back about
>>> a second or so every time I boot it, but nowhere near the gargantuan
>>> misalignment of Windows.
>>>
>>> Does anybody have any idea how to make these two guys live happily
>>> together sharing the clock? Yes, Fedora does use local time - at
>>> least, that's the way I installed it..
>>>
>>
>> Set UTC=false.
>>
>> ,----
>> | Setting UTC or local time
>> |
>> | When Linux boots, one of the initialisation scripts will run the
>> | /sbin/hwclock program to copy the current hardware clock time to the
>> | system clock. hwclock will assume the hardware clock is set to local
>> | time unless it is run with the --utc switch. Rather than editing the
>> | startup script, under Red Hat Linux you should edit the
>> | /etc/sysconfig/clock file and change the ``UTC'' line to either
>> | ``UTC=true'' or ``UTC=false'' as appropriate.
>> `----
>>
> You will have to double check, but running "hwclock --utc --systohc"
> makes this change systems I have worked with. Running
> "hwclock --localtime --systohc" will set it to local time.
>
> With both Windows and Linux on the same machine, you probably should
> have the hardware clock set to local time. Because the system time
> is written back to the hardware clock when FC shuts down, you can
> run into problem if it is not set correctly. If Linux expects UTC
> and Windows expects local time, both end up doing large corrections
> when they boot. You can end up with running corrections that are
> based on an incorrect drift rate because you are trying to adjust to
> the time zone difference every time you change the OS. You also run
> into this problem when you change the hardware clock from local time
> to UTC on a running system.

Switching back and forth between Windows and Linux in local time can still 
mess up at the daylight time/standard time boundaries.  Linux will adjust 
for daylight time only if it is running.  Windows always adjusts at the 
next boot after the change.  It's easy to construct scnearios where you 
are suddenly an hour off in one direction or the other.

Depending on how much time you spend in Windows, you might like this 
solution (which I use, but then I'm hardly ever in Windows):

Use UTC in Linux.  Set the Windows time zone to GMT and turn off the 
daylight-time adjustment for all users in Windows.  Then Linux does 
dalight time right and Windows won't screw it up.

Note that (I think) we've strayed off topic.  The OP is talking about 
drift of a few seconds or minutes at a time, not an hour or two or five or 
six that you would expect from timezone errors.  I know older kernels had 
clock drift issues on some machines, but I thought that had been fixed for 
some time now.  If ntp isn't doing the job (surprising, unless somehow it 
can't reach time servers or the drift strays too much too fast), then 
maybe adjtimex can help.

-- 
 		Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs