.NET CF 3.5 SetTimeZoneInformation problem

本文关键字：SetTimeZoneInformation problem CF NET | 更新日期: 2023-09-27 17:48:58

我想在c# CF 3.5应用程序中以编程方式设置时区。我想这样做的原因是，这个应用程序安装在数百个摩托罗拉MC55设备上，其中一些设备会定期放电。充电后，时区设备时区被设置为一些"外来"值，不等于我的时区(UTC+1华沙)。我使用OpenNETCF.WindowsCE.DateTimeHelper.SetTimeZoneInformation API来设置时区。我得到OpenNETCF.WindowsCE.TimeZoneInformation对象通过获取OpenNETCF.WindowsCE.TimeZoneCollection列表和搜索关键字"华沙"。因此，我有一个正确设置OpenNETCF.WindowsCE.TimeZoneInformation对象，我传递给OpenNETCF.WindowsCE.DateTimeHelper.SetTimeZoneInformation API调用。问题是这个时区是"夏令时"，最近(在最近的夏令时设置之后)我的应用程序中的当地时间比应该的时间晚了1小时。最好的是这个问题只存在于某些设备上，而不是所有设备上。

原因可能是什么?

OpenNETCF TimeZoneCollection直接从OS获取数据，它不做任何事情，只是充当数据编组器。如果你看到不正确的夏时制偏移量、夏时制日期或时区偏差，那是因为你的操作系统对这些定义不正确。

这并不罕见，特别是因为世界上不同的地方喜欢定期更改本地时间计算的定义，而操作系统构建不知道这些已经发生了。由于这个原因，许多CE 5.0和更早的设备仍然不正确地计算美国的夏令时更改日期。

解决方案是用一个具有正确定义的操作系统来更新设备。

现在，如果你看到一个问题，你把时区设置为像"UTC +1 PlaceA"，你得到返回"UTC +1 PlaceB"然后我认为这是一个已知的问题(我想我记得一些问题在过去的5年无论如何)，因为它没有很好地处理在操作系统。查看源代码:

public static void SetTimeZoneInformation( TimeZoneInformation tzi )
{
    // Call CE function (implicit conversion occurs to
    // byte[]).
    if (!NativeMethods.SetTimeZoneInformation(tzi))
    {
        throw new System.ComponentModel.Win32Exception(
            Marshal.GetLastWin32Error(), "Cannot Set Time Zone");
    }
}

你可以看到，我们只是传递从设备检索的TZI(在非winmo的情况下从注册表)，并在TimeZoneCollection类中组装(从第129行开始)。

在我们创建的必须处理时区、DST等的解决方案中，我们实际上最终编写了自己的服务来处理所有DST/TZ计算。我们使用操作系统来存储GMT，然后手动完成所有偏移。该产品在几个国家销售，覆盖了几个时区，我们没有听说过任何问题(因为它是一个时钟，任何与时间有关的问题都会很快显现出来)。