Hi,

I'm reworking the 4.2 OS for a device that I have which includes a
battery-backed real-time clock for daylight saving time adjustments. I have
the clock itself working fine and transitions between daylight saving time
and standard time work fine when the device is on, but transitions that
occur when the A/C power to the device is off are not reflected. That is,
this year, if you had this device set for Pacific time and you turned it off
before the weekend of the 29th and 30th of October, you would not see the
adjustment from Pacific Daylight Time back to Pacific Standard time.
However, if you left the power on, you *would* see the change on Monday (and
the pop-up dialog that the shell shows indicating that the time was
adjusted).

So, there's this key in the registry, HomeDST, that seems like it might be
designed to use to notify the shell that, when the device was turned off, it
was in daylight mode or standard mode, so that the shell can figure out
that, hey, while we were off, a transition occurred, and adjust the clock.
However, despite the comments in the HPC Explorer shell dst.cpp file, it
does *not* seem to handle transitions while power is off, as far as I can
tell (unless someone else that I don't have the source for is doing it).

So, what's the design here? Do I have to create something to run before the
shell and check for a mismatch between the calculated daylight/standard flag
and the one in the registry?

Also, how can I catch changes to the DST flag? The call to
SetDaylightTime() doesn't seem to end up in an OEMSetDaylightTime() where I
can easily save the new flag value. Do I have to replace the coredll API
call? Can I easily replace the kernel call, while still retaining the
ability to call the default routine?

Paul T.

Re: DST Adjustments by Paul

Paul
Wed Jan 12 13:31:05 CST 2005

Anyone? So far, I've modified the HPC shell to do the right thing when the
HomeDST value in the registry doesn't match the DST setting that it thinks
should be set, based on the time zone and date/time.

I still have the problem of accurately detecting and handling the
SetDaylightTime() changes. Please help me figure out how to detect such
changes!

If you have suggestions on better ways to handle the
transition-while-power-off case, I'll still take them, too!

Paul T.

"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:O52vduC%23EHA.824@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> I'm reworking the 4.2 OS for a device that I have which includes a
> battery-backed real-time clock for daylight saving time adjustments. I
> have the clock itself working fine and transitions between daylight saving
> time and standard time work fine when the device is on, but transitions
> that occur when the A/C power to the device is off are not reflected.
> That is, this year, if you had this device set for Pacific time and you
> turned it off before the weekend of the 29th and 30th of October, you
> would not see the adjustment from Pacific Daylight Time back to Pacific
> Standard time. However, if you left the power on, you *would* see the
> change on Monday (and the pop-up dialog that the shell shows indicating
> that the time was adjusted).
>
> So, there's this key in the registry, HomeDST, that seems like it might be
> designed to use to notify the shell that, when the device was turned off,
> it was in daylight mode or standard mode, so that the shell can figure out
> that, hey, while we were off, a transition occurred, and adjust the clock.
> However, despite the comments in the HPC Explorer shell dst.cpp file, it
> does *not* seem to handle transitions while power is off, as far as I can
> tell (unless someone else that I don't have the source for is doing it).
>
> So, what's the design here? Do I have to create something to run before
> the shell and check for a mismatch between the calculated
> daylight/standard flag and the one in the registry?
>
> Also, how can I catch changes to the DST flag? The call to
> SetDaylightTime() doesn't seem to end up in an OEMSetDaylightTime() where
> I can easily save the new flag value. Do I have to replace the coredll
> API call? Can I easily replace the kernel call, while still retaining the
> ability to call the default routine?
>
> Paul T.
>
>