Daylight Savings Time

[MDB]

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);

 

[Guest]

Can you be a little more specific on what you've done, what actually
happened and what you expected?

Your device probably does not have the registry info for the new DST rules
for the US. The "fix" for that is a new set of registry entries for US time
zones. Once applied, the device should work fine - the CF has nothing to do
with that specifically - the clock is maintained by the kernel.

However, when dealing with time zones you must keep in mind that the CF
doesn't always go to the registry for it's information. It loads the
timezone when the app is loaded, and then chaches that value for the life of
the app. So if your run your app, then modify the timezone, your app will
not see that change reflected in DateTime.Now unless you restart the app.

The workaround is that you should always directly call GetSystem/LocalTime
if you have any possibilty of timezones changing during the life of the app.

 

[Paul G. Tobey [eMVP]]

On what device/device type?!

Paul T.

 

[MDB]

Okay, I did apply the fix for the new DST rules, changed the clock to 1:59
AM on 3/11/07. Once the clock hit 2:00 it didn't adjust to 3:00AM like it
should have.

In order to get the clock to automatically adjust to 3:00 for the daylight
savings, I had to adjust the time zones. After I adjusted the time zone,
and then changed the clock to 1:59 on 3/11/07 it DID automatically adjust to
3:00 as it should. I don't really want to change the time zone however,
that is what I had to do in order to get the new registry values to work.

The reason I was using opennetcf was due to thinking if I manually changed
the time zone for the device to adjust automatically for DST that if I set
it using OpenNETCF.Web.Services2.TimeZone.SetTimeZoneInfo(originaltz); it
would do the same as manually changing.

My device is a WM2003 with CF 1

So it basically comes down to, what else needs to be done after applying the
DST rules fix for it to work?

 

[MDB]

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:[email protected]...

 

[Paul G. Tobey [eMVP]]

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.

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:[email protected]...

On what device/device type?!

Paul T.

 

[MDB]

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:[email protected]...

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.

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:[email protected]...

On what device/device type?!

Paul T.

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);

 

[Paul G. Tobey [eMVP]]

Now wait a minute. If soft reset doesn't work, there's something very wrong
with what you did...

Paul T.

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:[email protected]...

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.

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 On what device/device type?!

Paul T.

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);

 

[Guest]

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
--

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:[email protected]...

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.

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 On what device/device type?!

Paul T.

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);

 

[MDB]

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.

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
--

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:[email protected]...

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.

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 On what device/device type?!

Paul T.

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);

 

[Paul G. Tobey [eMVP]]

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.

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.

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
--

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 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.

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
On what device/device type?!

Paul T.

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);

 

[MDB]

Yes, cold boot equals Hard Reset, warm boot equals soft reset.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:[email protected]...

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.

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.

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
--



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 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.

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
On what device/device type?!

Paul T.

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);