Setting the time Zone with OpenNETCF

[RDub]

I am trying to programmatically set the Device Date and time using
OpenNETCF V1.4 on a PocketPC2003 SE and CF1.0. Here is the code I am using:

Private Sub SetSystemDateTime(ByVal strTimeZoneDisplayName As String, _
ByVal dteUTCDateTime As DateTime)
' Purpose Set the time zone and the UTC time and date using the
pram's passed

Dim TZI As OpenNETCF.Win32.TimeZoneInformation = New _
OpenNETCF.Win32.TimeZoneInformation
Dim tziInfo As New OpenNETCF.Win32.TimeZoneCollection

tziInfo.Initialize()
' Iterate each time zone looking for the one that we want to use
For Each tziItem As OpenNETCF.Win32.TimeZoneInformation In tziInfo
If tziItem.DisplayName = strTimeZoneDisplayName Then
TZI = tziItem
' Set the TimeZone First
OpenNETCF.Win32.DateTimeEx.SetTimeZoneInformation(TZI)
' Then Set the Local Time for that zone
OpenNETCF.Win32.DateTimeEx.SetSystemTime(dteUTCDateTime)
File.Create(Global.SqlDataScriptPath & "NoError.txt")
Exit For
End If
Next
End Sub

For the most part this code works great, Except when attempting to set the
"GMT-5 Eastern US". As often as not when I inspect the device after making
this call the time Zone is set to "GMT-5 Indiana (USA)". I have stepped
through the code and checked the values in TZI just prior and after the line
"OpenNETCF.Win32.DateTimeEx.SetTimeZoneInformation(TZI)", and all appears
OK. Obviously this aint the end of the world as both time zones have the
same offset, and perhaps even the same DST info (not sure though), but it is
"wrong", and I have not tested all of the other likely suspects (same
offsets, different Zone names). The date and time are correct after the
call, its just the Time Zone that's outa' wack.

In my testing I have been passing these two strings to the function.
"GMT-5 Eastern US"
"1/10/2008 10:32:49 PM"

Any and all help would be most appreciated. Thanks

Ron W

 

[Paul G. Tobey [eMVP]]

Hmmm. You'd really have to step through it. If the TZI value is identical
for both, it's quite possible that it would show as not one, but the other,
although I wouldn't really expect that (as the name of the timezone is part
of the TZI structure passed to SetTimeZoneInformation(), the API call).
What are the characteristics of the device on which this is happening, same
brand, model, OS date, etc.?

Paul T.

 

[Ron Weiner]

All of the Devices are Symbol MC50's, and all have been flashed with the
same (latest) version of Symbol's OS. All of the devices have also been
updated with the MSoft Daylight Savings Time changes. Tomorrow I will have
a look at and report the differences in the TZI's between the two timezones.
Been scratching my head over this one for a while now.

Ron W


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

 

[RDub]

Thanks for your help Paul. All of the Devices are Symbol MC50's, and all
have been flashed with the same (I believe most recent) version of Symbol's
OS.
MC50wseApp00B.hex
MC50wseIPL06270500.hex
MC50wseOS12120500.bgz
MC50wsePlat019.hex
MC50wsePt64M003.hex

All of the devices have also been updated with the MSoft Daylight Savings
Time changes. (WM2k23DST_unsigned.cab)

Here is what I see when I look at the elements of the TZI structure for the
two time zones on our devices. (hope the formatting does not get to bollixed
up by newsreader word wrapping.

GMT-5 Eastern US GMT-5 Indiana (USA)
=============== ==================
Bias 300 300
DaylightBias -60 -60
DaylightDate {OpenNETCF.Win32.SystemTime} {OpenNETCF.Win32.SystemTime}
Day: 0 Day: 0
DayOfWeek: 0 DayOfWeek: 0
Empty: {OpenNETCF.Win32.SystemTime} Empty:
{OpenNETCF.Win32.SystemTime}
Hour: 0 Hour: 0
Milliseconds: 0 Milliseconds: 0
Minute: 0 Minute: 0
Month: 0 Month: 0
Second: 0 Second: 0
Year: 0 Year: 0
DaylightName Eastern Daylight Tim US Eastern Daylight Tim
DisplayName GMT-5 Eastern US GMT-5 Indiana (USA)
StandardBias 0 0
StandardDate {OpenNETCF.Win32.SystemTime} {OpenNETCF.Win32.SystemTime}
Day: 0 Day: 0
DayOfWeek: 0 DayOfWeek: 0
Empty: {OpenNETCF.Win32.SystemTime} Empty:
{OpenNETCF.Win32.SystemTime}
Hour: 0 Hour: 0
Milliseconds: 0 Milliseconds: 0
Minute: 0 Minute: 0
Month: 0 Month: 0
Second: 0 Second: 0
Year: 0 Year: 0
StandardName Eastern Standard Tim US Eastern Standard Tim

I cant even begin to imagine why "? tziitem.StandardDate" from the immediate
window produces empty system time structures as shown above, but it does. I
can also tell you that "GMT-5 Indiana (USA)" is the very next item in the
list after "GMT-5 Eastern US".

Sure would appreciate any help you folks could provide.

Ron W




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

 

[Paul G. Tobey [eMVP]]

This appears to be a feature of Pocket PC 2003. The Date/Time applet
doesn't appear to care what the current name of the set time zone is, only
what its characteristics are. It then seems to pick the first one that it
finds in its own list of time zones and shows that as "current". The
regular Windows CE.NET (which is all I have to really test on real devices),
seems to do the right thing, using the Standard Name and Daylight Name to
pick the right zone.

Note that the display name doesn't actually exist in the structure that's
passed back and forth to CE, so, unless you set it yourself, as the
TimeZoneCollection does, it's just going to be null. I thought that I was
helping out by putting that in there, but it kind of hides the fact that PPC
isn't really working the same way as CE.

I don't really have any recommendation as to something that you can do,
either. You could play around with the contents of the TZI structure before
it's sent to SetTimeZoneInformation(), but I'm not sure that there's really
a 'fix'. Not sure why you're sometimes getting the right thing and
sometimes not, either.

Paul T.

Thanks for your help Paul. All of the Devices are Symbol MC50's, and all
have been flashed with the same (I believe most recent) version of
Symbol's OS.
MC50wseApp00B.hex
MC50wseIPL06270500.hex
MC50wseOS12120500.bgz
MC50wsePlat019.hex
MC50wsePt64M003.hex

All of the devices have also been updated with the MSoft Daylight Savings
Time changes. (WM2k23DST_unsigned.cab)

Here is what I see when I look at the elements of the TZI structure for
the two time zones on our devices. (hope the formatting does not get to
bollixed up by newsreader word wrapping.

GMT-5 Eastern US GMT-5 Indiana (USA)
=============== ==================
Bias 300 300
DaylightBias -60 -60
DaylightDate {OpenNETCF.Win32.SystemTime} {OpenNETCF.Win32.SystemTime}
Day: 0 Day: 0
DayOfWeek: 0 DayOfWeek: 0
Empty: {OpenNETCF.Win32.SystemTime} Empty:
{OpenNETCF.Win32.SystemTime}
Hour: 0 Hour: 0
Milliseconds: 0 Milliseconds: 0
Minute: 0 Minute: 0
Month: 0 Month: 0
Second: 0 Second: 0
Year: 0 Year: 0
DaylightName Eastern Daylight Tim US Eastern Daylight Tim
DisplayName GMT-5 Eastern US GMT-5 Indiana (USA)
StandardBias 0 0
StandardDate {OpenNETCF.Win32.SystemTime} {OpenNETCF.Win32.SystemTime}
Day: 0 Day: 0
DayOfWeek: 0 DayOfWeek: 0
Empty: {OpenNETCF.Win32.SystemTime} Empty:
{OpenNETCF.Win32.SystemTime}
Hour: 0 Hour: 0
Milliseconds: 0 Milliseconds: 0
Minute: 0 Minute: 0
Month: 0 Month: 0
Second: 0 Second: 0
Year: 0 Year: 0
StandardName Eastern Standard Tim US Eastern Standard Tim

I cant even begin to imagine why "? tziitem.StandardDate" from the
immediate window produces empty system time structures as shown above, but
it does. I can also tell you that "GMT-5 Indiana (USA)" is the very next
item in the list after "GMT-5 Eastern US".

Sure would appreciate any help you folks could provide.

Ron W




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

Hmmm. You'd really have to step through it. If the TZI value is
identical for both, it's quite possible that it would show as not one,
but the other, although I wouldn't really expect that (as the name of the
timezone is part of the TZI structure passed to SetTimeZoneInformation(),
the API call). What are the characteristics of the device on which this
is happening, same brand, model, OS date, etc.?

Paul T.