[OT] Time setting (was: Re: public import and bugs it causes)

[Steven Schveighoffer]

On Fri, 14 May 2010 21:01:15 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Alex Makhotin wrote:
>> Andrei Alexandrescu wrote:
>>>
>>> Date: Sat, 15 May 2010 04:46:08 +0300
>>>
>>> That's a bit in the future. Any chance I could impose on you to change  
>>> your system time?
>>  Every time I set the local time in Linux and then reload to Windows,  
>> the Windows resets it in BIOS. So I set the Linux to use the UTC(as in  
>> BIOS). To use the local time it requires me to set the clock back on 2  
>> hours. I don't know why Windows resets BIOS clock...
>
> Interesting. Can you instruct Windows to sync using the Internet? And  
> does Windows have the right time zone set?

Having dealt with a customer that insisted we always have the time set  
properly, I can tell you that Windows uses the BIOS time as local time,  
Linux *can* use the BIOS time as local time, but generally assumes it is  
set to UTC (and adjusts it's working clock accordingly).  During halt, it  
saves the clock back to the BIOS in case anything has changed, and  
generally uses UTC.

What is actually happening is that Windows *is* setting the time via the  
internet, and then overwriting the BIOS time :)

AFAIK, the only way to fix this is to configure linux to treat the BIOS  
time as local time.  Do a man on hwclock, and read the notes at the  
bottom.  Since every Linux system has its own init scheme, it probably  
varies from system to system.  I'm pretty sure the kernel reads the HW  
clock the first time, but once it reads it, it doesn't use it anymore.   
halt usually sets the clock using hwclock.  You can probably override the  
kernel time by doing a hwclock read very early in the process, but that  
means the kernel will think the time is off by whatever your timezone is  
when it is starting up.  This would probably best be done in the initrd  
before the filesystem is mounted.  There may be kernel parameters that  
force this mode of reading the clock.

Funny anecdote (actually not really funny at the time):  Our windows test  
image for previously mentioned customer was set to use UTC time, but had  
the checkbox set for "adjust for daylight savings"  Well, there is no  
daylight savings in UTC, but Windows still seemed to think during sysprep  
that it was a good idea during certain dates of year to set the BIOS clock  
ahead one hour.  Since we booted twice during sysprep, all clocks went out  
the door off by 2 hours.  This did not go over well with said customer,  
and we had to recall all the systems so they could be set properly (yes,  
I'm not making this up, we had to boot these systems to our network, which  
automatically set the time, and then shut them down).

-Steve