Re: DST Adjustments
From: Paul G. Tobey [eMVP] (ptobey)
Date: 01/14/05
- Next message: Paul G. Tobey [eMVP]: "Re: When do I use IP_ADAPTER_INFO.CurrentIpAddress?"
- Previous message: Troy Anderson: "When do I use IP_ADAPTER_INFO.CurrentIpAddress?"
- In reply to: Paul G. Tobey [eMVP]: "Re: DST Adjustments"
- Next in thread: Paul G. Tobey [eMVP]: "Re: DST Adjustments"
- Reply: Paul G. Tobey [eMVP]: "Re: DST Adjustments"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 14 Jan 2005 10:58:12 -0700
OK, I have everything working with a single exception. I'm going to need
someone with significant kernel experience to help with this one, I think.
First, what works: I have adjusted the shell code so that, when a
'transition' occurs, it saves the next transition time (it saves the October
change-over time when the spring transition occurs, since October is the
next one, etc.), in non-volatile memory. The kernel has also been modified
so that, each time the clock is changed by software, it also stores the
current DST flag at that point (it does this in OEMSetRealTime). Finally,
the shell code has been changed so that, when the shell starts, it compares
the current local time to the saved, non-volatile next-transition time. If
that time has passed, while the unit was powered-off, we missed at least one
transition. The shell then uses the current time to figure out whether it
thinks we should be in DST or standard time. That result is then compared
to the stored DST flag. If they match, we seem to have missed an even
number of transitions, so the clock is not adjusted. If they don't match,
we've missed an odd number of transitions and the clock is updated
appropriately.
The only remaining problem is this: I really need to capture changes to the
DST flag by injecting my own code in place of SC_SetDaylightTime, not by
trying to catch the current state of the flag in OEMSetRealTime. Since,
anyone can change the DST flag at any time by calling SetDaylightTime,
there's no guarantee that the flag state when OEMSetRealTime is called will
be the state on which the time was set.
****
So, I need a means to change where the entry for SC_SetDaylightTime in the
Win32 API pointer array points. I've tried to find a way to trick the
compiler and linker into replacing the entry defined in PRIVATE code with my
entry. I've tried changing the entry (despite it's 'const' declaration),
during various parts of the startup, but that doesn't seem to work.
HELP, PLEASE!
****
Paul T.
"Paul G. Tobey [eMVP]" <ptobey no spam AT no instrument no spam DOT com>
wrote in message news:%23l0mJiZ%23EHA.2572@tk2msftngp13.phx.gbl...
> Yep, it's strange. I think that I can make it work, if I keep track of a
> few extra things, besides the local time, while the power is off.
>
> I'm betting that the reason local time is saved to the real-time clock,
> rather than system time is that what you ask for from applications running
> on the device is local time, not GMT. That is, what do you display or
> save as the acquisition time of some data or the clock-in time of some
> employee? Local time. If, every time you fetched the local time, you had
> to do some comparisons to the DST transition time and, potentially,
> perform some calculations, getting the local time would be slow. Now, you
> have to do strange things like set alarms, reset them when one occurs,
> etc. and, potentially adjust the time. However, getting the local time is
> very fast (or as fast as we can reasonably expect it ever to be. It's a
> guess, but logical, I think.
>
> I'll post back if I ever get this to work!
> Paul T.
>
> "P" <nospamp@hotmail.com> wrote in message
> news:9af9d7fd.0501130155.6462d414@posting.google.com...
>> Hi,
>>
>> I can't really help but we have run into the same problem. The
>> mechanism for switching to and from savings time cannot work during
>> power-off and I don't think there's a quick solution to it. Maybe the
>> best thing would be to set your system to GMT without DST and then
>> calculate your local time yourself.
>>
>> In my opinion, the current CE implementation is terrible. The correct
>> way to do it is using local time and system time. System time should
>> not care about DST and local time should be (where I live) system time
>> + 1 or system time + 2 depending on the time of the year. That way,
>> the system time that is saved in your RTC will just keep running and
>> if you were in power-off during the transition, on power-on you will
>> see "November? Must be winter time".
>> NOTHING has to happen at the time of the transition, because from the
>> system time you can ALWAYS tell the local time. I really don't know
>> why a timer is set at the time a a transition, it's completely
>> unnecessary.
>>
>> I haven't started working on a better implementation and frankly I
>> don't think I will, because in our application we use SNTP regularly
>> and that solves the problem.
>>
>> If you want to give it a try, I'm very interested though.
>>
>> Some problems you might run into:
>> 1) DST is implemented in shell instead of kernel which means that
>> using a custom application without shell is just as good as being in
>> power-off. (!)
>> 2) There appears to be a bug that causes us to save local time to the
>> RTC instead of system time. Very funny, because if it's sunday
>> 2004/10/31 02:30 am, you have no idea whether the transition has
>> passed already. If you would be able to program system time, this
>> issue would not arise.
>>
>> If you do a few tests, you will see what strange results you can get.
>>
>> Good luck,
>> Piet
>>
>> pietdesomere a t yahoo d o t com
>>
>>
>>> 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.
>
>
- Next message: Paul G. Tobey [eMVP]: "Re: When do I use IP_ADAPTER_INFO.CurrentIpAddress?"
- Previous message: Troy Anderson: "When do I use IP_ADAPTER_INFO.CurrentIpAddress?"
- In reply to: Paul G. Tobey [eMVP]: "Re: DST Adjustments"
- Next in thread: Paul G. Tobey [eMVP]: "Re: DST Adjustments"
- Reply: Paul G. Tobey [eMVP]: "Re: DST Adjustments"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|