Setting the Time Zone with Compact Framework on Windows Mobile 6

Question

First, background: I have a .Net application that runs in kiosk mode on Windows Mobile 6 devices (IPAQ 210s). Our software actually tracks the user's time zone independently of the operating system, so we calculate the displayed time based on their time zone adjustment from UTC. As many may know, true kiosk mode is not easy to achieve on Windows Mobile 6, and final piece of the puzzle for this app is suppressing the DST notifications from the OS.

My preferred solution to this would be set the device timezone to GMT Casablanca, since it doesn't observe DST. I've discovered, however, that despite my best efforts (including using the OpenNETCF library) I cannot get the time zone to reliably stick during the device provisioning process. In the date/time applet in the OS, it looks like the timezone is GMT, but the time is one off from what it should be for that timezone.

Can anyone offer advice as to how to get the timezone change to stick properly? Or, better yet, does anyone know how to disable the DST notification on WinMob 6?

Answer 1

You can set it in the registry. Just set the HKLM\Time\TimeZoneInformation value. There is also a function you can pinvoke: SetTimeZoneInformation.

Answer 2

I have also encountered the off by one error when changing timezones but in eVC not CF yet. In the end, I decided that it was being caused by changing the timezone of the device from a timezone that was in DST already to a timezone that was not in DST. It appeared to work correctly for the months of the year that we were on standard time but failed when we were on daylight savings time. Very annoying.

In the end, I ended up setting the timezone and times twice. It was (usually) correct the second time.

Answer 3

I've experienced the same off-by-one-hour DST error in Windows Mobile 5. The problem appears to be OS-related rather than .NET-related, since I was using the SetSystemTime API call on the device, passing the server's DateTime.UtcNow value (which was always accurate and never off by an hour). I was never able to trace the problem further, because we made the decision to keep all devices set to the same time zone as the server. The error only occurred when setting the system time on a device set to a different time zone than the server.

I've never seen this problem reported anywhere, despite extensive searching, which means one of the following is true:

1. Most WinMo device users set their own time and timezone manually, so this problem never comes up
2. The problem is build-specific rather than generally OS-specific (the problem I saw was on an iPAQ, but I don't remember if I tried to reproduce the problem on a different device)
3. I'm clinically insane, and this never really happened

Answer 4

For whatever reason, the CF actually caches timezone info at startup (I think the full framework does too). So when you make changes to the timezone, the CF is unaware of those changes. If you use the GetSystem/LocalTime APIs, you'll get the right time but DateTime.Now will not reflect those changes.

I reported this back in 2004.

On the desktop you have the TimezoneInfo.ClearCachedInfo method, but it doesn't exist in the CF.