Setting the time with opennetcf seems to modify the time zone...

[Guest]

Hi,

I'm setting the system time using OpenNETCF's DateTimeEx. I get the time,
in UTC, from SAP R/3.

Often (but not always), the timezone changes a few seconds after calling (or
it's visible a few seconds after that) SetSystemTime. The clock in the upper
right moves a (seemingly random) number of hours, and the application logs
show the same behaviour.

This timezone thing is my guess, anyway, could be something else. The one
thing I know for sure is that the time we receive from SAP is correct, so
either we are calling SetSystemTime incorrectly (unlikely, it's too simple,
plus it works sometimes) or SetSystemTime isn't working as expected.

By the way, how can I programatically set the time zone?

I'm using .NET CF 1.1SP3. The device is an Intermec 750 with PPC2003.

Thanks.

 

[Peter Foot [MVP]]

The TimeZone is set using GetTimeZoneInformation / SetTimeZoneInformation
API calls which are also wrapped by the DateTimeEx class. As for why the
clock is showing odd behaviour on setting the time - check what the timezone
is set to before and after the update and see if anything changes, also log
the time you receive from the server and confirm that it is a valid UTC
time.

Peter

 

[John Roberts]

We had great 'fun' trying to set the time and timezone information of the
client at the same time. This is our final code:

TimeZoneInformation timeZoneInformation = new
TimeZoneInformation(response.m_timezone);
DateTime now = DateTime.FromFileTimeUtc(response.m_utcNow);
//set timezone information and flush the time zone cache so it is re-read
DateTimeEx.SetTimeZoneInformation(timeZoneInformation);
FieldInfo fi = typeof(TimeZone).GetField("currentTimeZone",
BindingFlags.NonPublic|BindingFlags.Static|BindingFlags.Instance);
fi.SetValue(null, null);
DateTimeEx.SetDaylightTime(false);
DateTimeEx.SetSystemTime(now);

Other combinations of calls didn't work with results ranging from the hour
being increased or decreased each time, and in some cases DST was wrong. The
above works consistently across time zones and in awkward periods where DST
is on in the time zone you are moving from and off in time zone you are
moving to, or vice versa.

BTW, we construct the TimeZonInformation structure on the server.

Hope this helps,
- John