Re: Daylight Savings Time

The hazards of Windows Mobile... When you say "cold boot" and "warm boot",
can you confirm that you're doing what is more-commonly called "hard reset"
and "soft reset" in the Pocket PC world? I presume that, when there's an
actual fix from Microsoft, the right things will happen and I can't explain
(we don't have the Windows Mobile shell source code), what it's doing wrong.
The Windows CE shell would not have this problem, as it recalculates the
next DST transition time each time the shell starts. I suppose that the
global DST flag might already be in the ON state, so there's no transition,
or something. You can call GetTimeZoneInformation() to see the current flag
state and SetDaylightTime() to set it one way or the other.

Fooling around with the time right near the transition point can cause the
system to change the flag state and, once DST is set to ON, it won't do
anything at the transition point. When I'm testing this in Windows CE, I
set the date/time well before the transition point, adjust the time first to
say, 1:45am, applying the changes, then changing the date to the transition
Sunday, in a separate operation. If you have the time set to 7am and you
set the date to the transition Sunday, bang, you're in daylight time,
setting it back to 1:50am will *not* undo that, or at least not always. The
sequence of operations is very important to getting things to the state you
want for the test.

Paul T.

"MDB" <mdb@xxxxxxxxxxx> wrote in message
news:un34sTfSHHA.3592@xxxxxxxxxxxxxxxxxxxxxxx
Okay, here is what I tried.

1st Test:

I ran the cab file I found here to fix the time zone issue.
http://www.edgeblog.net/2007/daylight-saving-time-windows-mobile-fix/
Set the Time to 1:50 AM on 3/11/07
Ran a registry save.
Warm booted the unit.

At 2:00 am nothing happend (it didn't move ahead one hour).

Now I cold booted the unit to make sure everything was back to default.

2nd Test

I ran the cab file to fix the time zone issue.
Set the Time to 1:50 AM on 3/11/07
Ran a registry save.
Allowed unit to suspend.
Woke unit up and then warm booted.
At 2:00 AM Nothing Happend.

Cold booted the unit to make sure everything was back to default.

3rd Test

I ran the cab file to fix the time zone issue.
Set the Time to 1:58 AM on 3/11/07 and Changed the Time Zone
At 2:00 AM Nothing Happend.

Cold booted the unit to make sure everything was back to default.

4th Test

I ran the cab file to fix the time zone issue.
Set the Time to 1:58 AM on 3/11/07
Closed time box.
Opened time again and changed the time zone.
At 2:00 AM it DID jump to 3:00 AM.




"<ctacke/>" <ctacke[@]opennetcf[dot]com> wrote in message
news:uoIaMoWSHHA.1600@xxxxxxxxxxxxxxxxxxxxxxx
You're certain the registry was persisted before your reset? Do a
suspend resume then a reset and see if that changes the behavior.


--
Chris Tacke
OpenNETCF Consulting
Managed Code in the Embedded World
www.opennetcf.com
--



"MDB" <mdb@xxxxxxxxxxx> wrote in message
news:OP2ojhWSHHA.4832@xxxxxxxxxxxxxxxxxxxxxxx
I did try a soft reset after making running the registry fix and
unfortunatly, it didn't work. I will try your suggest and try using the
Remote Spy. That is something I have never used so hopefully it is
pretty self explanatory.

Thanks

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message news:u6TuVkVSHHA.4028@xxxxxxxxxxxxxxxxxxxxxxx
OK, so it's a WM device. I think that, in order to get the shell,
which is the piece that handles DST transitions to know about your
change to the registry, you're going to have to either soft reset the
device (which starts all of the auto-start programs, including the
shell, again, and this time it will load a different set of registry
settings), or you're going to have to figure out what message is sent
from the control panel when you make a change to the timezone and
duplicate that (you might try Remote Spy++ to see if there's a
WM_SETTINGCHANGE message sent).

For consistency, I'd be much more inclined to just require a soft
reset. You know that it will work. In that case, all you have to be
sure of is that the registry has been persisted before you push the
reset button.

Paul T.

"MDB" <mdb@xxxxxxxxxxx> wrote in message
news:enmORfVSHHA.5016@xxxxxxxxxxxxxxxxxxxxxxx
It is an intermec 76x using WM2003 and CF1.



"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam
DOT com> wrote in message
news:OxC2NUVSHHA.2256@xxxxxxxxxxxxxxxxxxxxxxx
On what device/device type?!

Paul T.

"MDB" <mdb@xxxxxxxxxxx> wrote in message
news:eMVEtEVSHHA.412@xxxxxxxxxxxxxxxxxxxxxxx
I just ran the registry changes for the daylight savings changes and
changed the date and time to 1:59 AM on 3/11/07 and when the time hit
2:00 it didn't change. In order for the time to change to 3:00 like
it should, I have to apply the reg fix and then manually change the
time zone and then exit and then change it back. So my question is,
how can I do this pragmatically? I tried using the opennetcf by
calling the code below however, it still wouldn't work.

OpenNETCF.Web.Services2.TimeZone.TIME_ZONE_INFORMATION originaltz =
OpenNETCF.Web.Services2.TimeZone.GetTimeZoneInfo();
OpenNETCF.Web.Services2.TimeZone.SetTimeZoneInfo(originaltz);















.

Quantcast