Question

我想以编程方式在C＃CF 3.5应用程序中设置时区。我想这样做的原因是应用程序安装在数百台Motorola MC55设备上，其中一些设备定期出院。充电后，时区设备时区设置为某个“异国”值不等于我的时区（UTC + 1华沙）。我使用OpenNETCF.WindowsCE.DateTimeHelper.SetTimeZoneInformation API来设置时区。我通过获取OpenNETCF.WindowsCE.TimeZoneCollection列表并搜索关键字“Warsaw”来获取OpenNETCF.WindowsCE.TimeZoneInformation对象。因此，我有一个正确设置的OpenNETCF.WindowsCE.TimeZoneInformation对象，我传递给OpenNETCF.WindowsCE.DateTimeHelper.SetTimeZoneInformation API调用。问题是这个时区是“节日照明”，最近（在最近的夏令时设定之后）我申请的当地时间晚了1小时。最好的是，问题仅存在于某些设备上，而不是全部存在。

可能是什么原因？

Answer 1

OpenNETCF TimeZoneCollection直接从操作系统获取数据，除了充当数据封送器之外，它没有做任何事情。如果您看到不正确的DST偏移，DST日期或TZ偏差，那是因为您拥有的操作系统定义不正确。

这并不罕见，特别是因为世界各地都喜欢定期更改本地时间计算的定义，并且操作系统构建不知道这些已经发生过。由于这个原因，在那里仍有大量的CE 5.0及更早版本的设备仍在不正确地计算美国的DST更改日期。

解决方案是使用使用正确定义构建的操作系统更新设备。

现在，如果你看到一个问题，你将TimeZone设置为“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而不是其他任何东西，然后手动完成所有偏移。产品销售的是几个时区的几个快餐，我们听说没有问题（因为这是一个时钟，任何时间问题都会很快变得明显）。

.NET CF 3.5 SetTimeZoneInformation问题

1 个答案: