Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RAM-based EWF and Daylight Savings Time Change

117 views
Skip to first unread message

Doug Hoeffel

unread,
Mar 5, 2003, 10:56:34 AM3/5/03
to
Hello:

My product uses the RAM-based EWF, and I'm struggling with how to properly
detect, and adjust for, time changes due to daylight savings.

Currently, I have the Date/Time setting for the automatic adjustment for
daylight savings disabled. The reason for this is if the setting was set to
auto adjust then the system time would get re-adjusted by 1 hour on every
boot because the CMOS settings get adjusted. This is not acceptable as the
system time then becomes inaccurate in an incremental fashion. I currently
build my product with a time sync. mechanism which occurs at every boot-up
provided a network cable is connected. But, when my product is mobile,
there is no network cable, thus no time sync. The time on these cases may
be off by 1 hour (usually) depending on the time zone. The time sync.
update won't stick even on the next boot that has a network cable connected
since the RAM-based EWF is protecting the boot partition so this adjustment
is ignored.

So, I used regmon to try to figure out how Windows changes the local time,
based on time zone, when daylight savings starts and ends. The only reg
parameter that I noticed changing was
HKLM\System\CurrentControlSet\Control\TimeZoneInformation\ActiveTimeBias.
For my time zone (GMT-6) in standard time, ActiveTimeBias goes from 360 to
300 when going to daylight savings (GMT-5).

After searching MSDN etc. about all of this, I still can't determine how
Windows knows that it has already adjusted for daylight savings, i.e. what
keeps the time from changing by 1 hour on each boot after 6 April 2003 @ 2AM
for example?

What I'd really like to do is let Windows adjust the local time for daylight
savings, since Windows already knows how to reliably do this based on the
time zone, detect this change, then do a EWF -commit and reboot so the local
time gets properly saved. But, I don't want to get into a endless
commit/reboot cycle.

Anyone got any ideas? I'm curious how others are handling this problem.

Thanks... Doug


Wang Zirong

unread,
Mar 11, 2003, 7:28:12 AM3/11/03
to
Hi,

I have also similar problem with time zone, even without the time saving
enabled. Actually, imaging the first time we install, Windows assumes
the bios time is GMT, then when I change the time zone, say to GMT+1,
then the BIOS time get changed. this is OK but...

if we want to reinstall Windows Embedded, the same process applies, my
GMT+1 time in BIOS is supposed to be GMT+0, then, when I set the time
zone, the time is shifted 1 hour, imagine the third install.

The solution to this problem needs help from MS, is very simple: just
leave the BIOS time always store BIOS time in GMT(UTC) time. and,
depending on the current time zone, date and daylight saving setting,
present the time in a appropriate way, it is a matter of presentation.

Windows, as its grand brother dos 6.22, will always modify the bios when
time zone change, maybe even when daylight saving is needed.

Linux gives you the choice of storing BIOS in UTC. not Windows :-(

So I submitted a PSS case for this issue, asking if MS will implement
'store UTC time in BIOS' choice in the future, they first did not
understand, or they did not want to understand, then they told me it is
very unlikely due the backward compatibility, but I asked the choice,
not the behavior change, just have a setting in a reg key. sigh

Doug, if the BIOS was stored in UTC time, does it solve your problem ?

if so, please MS people, provide us this feature, even it is already
implemented in the 'devil/viral' Linux.


Zirong

Doug Hoeffel

unread,
Mar 11, 2003, 11:33:33 AM3/11/03
to
Hello:

Yes, if the BIOS stored the time in UTC, and Windows I/F worked that way,
then this would not be an issue. For more info. on this check out this
link:
http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html

For what it's worth, I found a work-around. I created a small registry hive
on a partition not protected by the EWF. I have a key that stores the
current mode of time zone, i.e. in daylight savings or standard time or
none. When my application starts, I use the Windows
GetTimeZoneInformation() API to check if this mode has changed. If so, I
update my registry hive, commit the changes to the partition protected by
EWF and perform a graceful restart. This way, the updated time is
persistant. This seems to work. This only causes 2 extra reboots per year
for time zones that adhere to daylight savings.

... Doug

"Wang Zirong" <nos...@blackhole.net> wrote in message
news:3E6DD65C...@blackhole.net...

0 new messages