BIOS time and Windows Question

[Gereon]

It seems to me that Windows treats the machine's BIOS time as being in local
time. Is that something that is configurable? Can it treat the BIOS time
as always being GMT, and internally adjust for that?

It seems like if the BIOS time was always GMT, then the logic for what time
it is locally (and the status of DST) would just be a calculation based on
what time zone you were in. No need to remember if you already adjusted for
DST on/ off transitions (and then, of course, no more EWF DST gotchas).

 

[Slobodan Brcin \(eMVP\)]

Gereon,

There is RealTimeIsUniversal registry entry and it almost work but during
the hours around the daylight change system will use 100% of processor time.
MS could easily change this though (they might have even fixed this in SP2)
:-(

http://groups-beta.google.com/group...0b5d645c55b/f5b4b659d09007e4#f5b4b659d09007e4
http://groups-beta.google.com/groups?q=RealTimeIsUniversal


Try this and let us know.

Regards,
Slobodan

 

[Gereon]

First Observation (In regular XP with SP2) : With RealTimeIsUniversal
registry entry on, Windows no longer adjusts my BIOS time. Bump clock ahead
in Windows, reboot, and the BIOS is unchanged and the time adjustment is
lost. But hey, that might not be such a bad thing.

More observations to come.

 

[Slobodan Brcin \(eMVP\)]

Gereon,

Read my observations in thread that I gave you. This is perfect option but
in hours around time switches it will take 100% of your CPU time in these
intervals.

BTW: What do you mean by time adjustement is lost? I have never seen this.

Do not set time from windows while you do these testings but do it from
BIOS.
And measure time difference between time reported by BIOS and time reposted
by windows, these times will tell us if this is working or not.

Regards,
Slobodan

 

[Gereon]

Hi Slobodan,

I think you have seen this behavior before, I'm just not describing it the
same way. You posted this in a message I found:

"Kernel function NtSetSystemTime does not call HalSetRealTimeClock when we
use RealTimeIsUniversal switch. But manually calling HalSetRealTimeClock
does change hardware time."

I think what I'm describing is a manifestation of this.

Moving on to my next observation:

Note: I have not seen any substantial CPU usage occurring during any of the
following tests. So maybe they fixed something. But it's still not
perfect.

I am in US Mountain Time here (GMT - 7:00), so early this Sunday morning at
2:00 am (9:00 am GMT) we should transition to DST and move to 3:00 am.

This is where strange things happen. When the CMOS clock rolls through 2:00
am on Sunday, Windows is displaying Saturday at 7:00 pm Standard Time, as it
should. If I reboot Windows at, say, 7:01, it will come up displaying 8:01
Daylight Savings Time. Something it elects to re- evaluate at boot time
makes it decide that it is DST, even though it is actually 7 hours too
early.

But not everything agrees. Our custom application has a special class to
handle times because we want to be able to display the time of an occurrence
in any given time zone. It uses GetSystemTime(...), GetTimeZoneInformation,
and SystemTimeToTzSpecificLocalTime(...) to generate the local time, and it
generates it correctly.

My XP Embedded target exhibits the same symptoms.

 

[KM]

"Kernel function NtSetSystemTime does not call HalSetRealTimeClock when we use RealTimeIsUniversal switch. But manually calling

HalSetRealTimeClock
does change hardware time."

I don't know about the NtSetSystemTime (ZwSetSystemTime) but the KeSetSystemTime does make a call to HalSetRealTimeClock which is
supposedly updates the real time (CMOS time).

The KeSetSystemTime is called regardless of whether the RealTimeIsUniversal flag is set. But if the flag is not set, the system
assumes the real time stored in in local time and will make the changes to the system time (to update it to universal time) early at
boot (and then call to KeSetSystemTime).

KM

 

[Slobodan Brcin \(eMVP\)]

Gereon,

If you are using custom shell then do not bother with undocumented switches,
but rather set windows to GMT+0 and disable daylight savings.
http://groups-beta.google.com/group...250fab5463c/fb387139782a5cc3#fb387139782a5cc3

You can use API functions that you mentioned for calculating correct time
based on this time and showing it in your shell.

I'll have to check changes in SP2 regarding the daylight savings to
RealTimeIsUniversal and see for my self what is happening.

Basically you should check time in BIOS and see what is time there whet
windows says 8:01.

Also try setting time in windows to some time what do you see in BIOS when
you do that?

Regards,
Slobodan

 

[Slobodan Brcin \(eMVP\)]

Konstantin,

I don't know about the NtSetSystemTime (ZwSetSystemTime) but the
KeSetSystemTime does make a call to HalSetRealTimeClock which is
supposedly updates the real time (CMOS time).

I will have to try this again but IIRC while RealTimeIsUniversal was under
effect you could not change CMOS time from windows. All changes would be
lost.

Regards,
Slobodan

 

[KM]

Slobodan,

I will have to try this again but IIRC while RealTimeIsUniversal was under
effect you could not change CMOS time from windows. All changes would be lost.

I do not argue about this fact I saw that the RealTimeIsUniversal is only used in kernel initialization routine and if set - no
updates to CMOS RTC happen.

 

[Gereon]

Hi Slobodan,
I think I've seen enough to scare me away from the RealTimeIsUniversal flag,
especially since the behavior is undocumented and could suddenly stop
working as expected in the future.

I'm thinking that setting the system to GMT+0 is the approach to take for
us. We do have a custom app for a shell, so we can translate any times we
need. I already do something similar anyway, just not everywhere in the
system.

Just to make sure though...By running in GMT+0 all the time, the system will
not update the BIOS time for any DST changes, and nothing time- related in
the registry needs to be preserved between resets (i.e. no DST problems when
running EWF)?

 

[Slobodan Brcin \(eMVP\)]

Gereon,

GMT+0 is not the key ingrediant for success but DisableAutoDaylightTimeSet
is.

Just set following:

HKLM\System\CurrentControlSet­\control\TimeZoneInformation]
"DisableAutoDaylightTimeSet"=d­word:00000001

Regards,

Slobodan