Setting correct TimeZone

  • Thread starter Thread starter PeterB
  • Start date Start date
P

PeterB

I know there are a bunch of threads covering this, but none seem to give a
solution that works.

I am trying to set the timezone of a PocketPC (WM2003SE) to "GMT+1
Berlin,Rome".

I am using SetTimeZoneInformation (OpenNETCF) with the following code:
TimeZoneInformation tzi = new TimeZoneInformation();
tzi.Bias = -60;
tzi.DaylightBias = -60;
tzi.DisplayName = "GMT+1 Berlin,Rome";
tzi.StandardName = "W. Europe Standard Time";
//tzi.DaylightName = "W. Europe Daylight Time";
DateTimeEx.SetTimeZoneInformation( tzi );

But the TimeZone is set to "GMT+1 W Cent Africa"...

How can I specify which of the GMT+1 alternatives should be selected???

Thanks!

/ Peter
 
Unfortunately, Pocket PC does not allow enumeration of available time zones
in the same way that generic Windows CE devices do. At least, we've never
found a way to do enumeration. If you set the time zone information
correctly to work, then whether the Date/Time control panel applet
interprets that right or not shouldn't affect the functionality of the
device.

One thing that you might look at is exporting the device registry before
changing the time zone with the Date/Time control panel applet. Set it to
GMT or something and export the registry using Remote Registry Editor. Then
set it to the target time zone that you want and do the same. Comparing the
..reg files on the desktop should indicate what, exactly, is changing and, if
you duplicate those changes in your code, you should have the same effect as
what the control panel is doing.

Paul T.
 
Hi!

Alex Feinman managed to extract the enumeration from a dll called
citydb.dll. He has done a testproject in csharp named CityDbTest. It works
1-way for me, i.e. I get all the names of the timezones, but I can't use it
to SET the timezone to something I want.

We don't bother with setting the time on our machines. Our customers will
create a parternship, and by default time is synched to PC time. But, when I
set the timezone to GMT+1 and W Cent Africa is selected, it seems like that
timezone doesn't use daylight saving (although I specify daylight offset
= -60), which we use. This means the time will be one hour off during summer
compared to the PC clock. This is why I can't accept the GMT+1 W Cent Africa
timezone....

I've already done the registry compare part:
STANDARD TIMEZONE:
[HKEY_LOCAL_MACHINE\Time]
"TimeZoneInformation"=hex:2c,01,00,00,45,00,61,00,73,00,74,00,65,00,72,00,6e,00,20,00,53,00,74,00,61,\
00,6e,00,64,00,61,00,72,00,64,00,20,00,54,00,69,00,6d,00,65,00,00,00,00,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,0a,00,00,00,05,\
00,02,00,00,00,00,00,00,00,00,00,00,00,45,00,61,00,73,00,74,00,65,00,72,00,\
6e,00,20,00,44,00,61,00,79,00,6c,00,69,00,67,00,68,00,74,00,20,00,54,00,69,\
00,6d,00,65,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,04,00,00,00,01,00,02,00,00,00,00,00,00,00,c4,ff,ff,ff

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Clock]
"GMT_OFFSET"=dword:0000012c
"AppInfo"=hex:01,00,00,00,5f,00,00,00,23,00,00,00,00,00,00,00,01,00,00,00,9d,01,00,00,23,\
00,00,00,00,00,00,00,01,00,00,00

BERLIN/ROME:
[HKEY_LOCAL_MACHINE\Time]
"TimeZoneInformation"=hex:c4,ff,ff,ff,57,00,2e,00,20,00,45,00,75,00,72,00,6f,00,70,00,65,00,20,00,53,\
00,74,00,61,00,6e,00,64,00,61,00,72,00,64,00,20,00,54,00,69,00,6d,00,65,00,\
00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,0a,00,00,00,05,\
00,03,00,00,00,00,00,00,00,00,00,00,00,57,00,2e,00,20,00,45,00,75,00,72,00,\
6f,00,70,00,65,00,20,00,44,00,61,00,79,00,6c,00,69,00,67,00,68,00,74,00,20,\
00,54,00,69,00,6d,00,65,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00,c4,ff,ff,ff

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Clock]
"GMT_OFFSET"=dword:ffffffc4
"AppInfo"=hex:01,00,00,00,5f,00,00,00,6e,00,00,00,00,00,00,00,01,00,00,00,9d,01,00,00,23,\
00,00,00,00,00,00,00,01,00,00,00

I'm manipulating the registry to invoke Swedish Reginal settings as well, so
I guess this could be the way to go...

I'm not sure how to import the hex numbers into the registry though, any
tips?

/ Peter
 
Whether and when to use DST is determined by values passed to the
SetTimeZone() API call. If it's not being set, you're not setting up the
time zone information passed to that call correctly. The
TimeZoneInformation entry in the registry gives the information about *when*
the DST transition occurs, etc. It's a binary version of the TZREG
structure, which you can find in the .h files from the C SDK for your
platform.

OpenNETCF's registry support will write binary values...

Paul T.

PeterB said:
Hi!

Alex Feinman managed to extract the enumeration from a dll called
citydb.dll. He has done a testproject in csharp named CityDbTest. It works
1-way for me, i.e. I get all the names of the timezones, but I can't use
it to SET the timezone to something I want.

We don't bother with setting the time on our machines. Our customers will
create a parternship, and by default time is synched to PC time. But, when
I set the timezone to GMT+1 and W Cent Africa is selected, it seems like
that timezone doesn't use daylight saving (although I specify daylight
offset = -60), which we use. This means the time will be one hour off
during summer compared to the PC clock. This is why I can't accept the
GMT+1 W Cent Africa timezone....

I've already done the registry compare part:
STANDARD TIMEZONE:
[HKEY_LOCAL_MACHINE\Time]
"TimeZoneInformation"=hex:2c,01,00,00,45,00,61,00,73,00,74,00,65,00,72,00,6e,00,20,00,53,00,74,00,61,\

00,6e,00,64,00,61,00,72,00,64,00,20,00,54,00,69,00,6d,00,65,00,00,00,00,00,\

00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,0a,00,00,00,05,\

00,02,00,00,00,00,00,00,00,00,00,00,00,45,00,61,00,73,00,74,00,65,00,72,00,\

6e,00,20,00,44,00,61,00,79,00,6c,00,69,00,67,00,68,00,74,00,20,00,54,00,69,\

00,6d,00,65,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,04,00,00,00,01,00,02,00,00,00,00,00,00,00,c4,ff,ff,ff

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Clock]
"GMT_OFFSET"=dword:0000012c
"AppInfo"=hex:01,00,00,00,5f,00,00,00,23,00,00,00,00,00,00,00,01,00,00,00,9d,01,00,00,23,\
00,00,00,00,00,00,00,01,00,00,00

BERLIN/ROME:
[HKEY_LOCAL_MACHINE\Time]
"TimeZoneInformation"=hex:c4,ff,ff,ff,57,00,2e,00,20,00,45,00,75,00,72,00,6f,00,70,00,65,00,20,00,53,\

00,74,00,61,00,6e,00,64,00,61,00,72,00,64,00,20,00,54,00,69,00,6d,00,65,00,\

00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,0a,00,00,00,05,\

00,03,00,00,00,00,00,00,00,00,00,00,00,57,00,2e,00,20,00,45,00,75,00,72,00,\

6f,00,70,00,65,00,20,00,44,00,61,00,79,00,6c,00,69,00,67,00,68,00,74,00,20,\

00,54,00,69,00,6d,00,65,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,\
00,00,00,00,03,00,00,00,05,00,02,00,00,00,00,00,00,00,c4,ff,ff,ff

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Clock]
"GMT_OFFSET"=dword:ffffffc4
"AppInfo"=hex:01,00,00,00,5f,00,00,00,6e,00,00,00,00,00,00,00,01,00,00,00,9d,01,00,00,23,\
00,00,00,00,00,00,00,01,00,00,00

I'm manipulating the registry to invoke Swedish Reginal settings as well,
so I guess this could be the way to go...

I'm not sure how to import the hex numbers into the registry though, any
tips?

/ Peter


Paul G. Tobey said:
Unfortunately, Pocket PC does not allow enumeration of available time
zones in the same way that generic Windows CE devices do. At least,
we've never found a way to do enumeration. If you set the time zone
information correctly to work, then whether the Date/Time control panel
applet interprets that right or not shouldn't affect the functionality of
the device.

One thing that you might look at is exporting the device registry before
changing the time zone with the Date/Time control panel applet. Set it
to GMT or something and export the registry using Remote Registry Editor.
Then set it to the target time zone that you want and do the same.
Comparing the .reg files on the desktop should indicate what, exactly, is
changing and, if you duplicate those changes in your code, you should
have the same effect as what the control panel is doing.

Paul T.
Click to expand...
Click to expand...
 
Back
Top