.NET CF 3.5 SetTimeZoneИнформационная проблема - PullRequest
Новая
       30

.NET CF 3.5 SetTimeZoneИнформационная проблема

0 голосов
/ 04 апреля 2011

Я хочу программно установить часовой пояс в приложении C # CF 3.5.Причина, по которой я хочу это сделать, заключается в том, что приложение установлено на сотнях устройств Motorola MC55, и некоторые из них периодически разряжаются.После зарядки часовой пояс устройства устанавливается на «экзотическое» значение, не равное моему часовому поясу (UTC + 1 Варшава).Я использую OpenNETCF.WindowsCE.DateTimeHelper.SetTimeZoneInformation API для установки часового пояса.Я получаю объект OpenNETCF.WindowsCE.TimeZoneInformation путем получения списка OpenNETCF.WindowsCE.TimeZoneCollection и поиска по ключевому слову «Варшава».Таким образом, у меня есть правильно установленный объект OpenNETCF.WindowsCE.TimeZoneInformation, который я передаю в вызов API OpenNETCF.WindowsCE.DateTimeHelper.SetTimeZoneInformation.Проблема в том, что этот часовой пояс является "Дневным светом", и недавно (после установки недавнего летнего времени) местное время в моем приложении на 1 час позже, чем должно быть.Лучше всего то, что проблема существует только на некоторых устройствах, а не на всех.

В чем может быть причина?

1 Ответ

2 голосов
/ 04 апреля 2011

OpenNETCF TimeZoneCollection получает данные непосредственно из ОС, ничего не делает, а действует как маршалер данных. Если вы видите неправильные смещения DST, даты DST или смещения TZ, это происходит из-за того, что в вашей ОС они определены неправильно.

В этом нет ничего необычного, особенно если учесть, что разные части мира периодически меняют определения для расчетов по местному времени, а сборка ОС не подозревает, что это произошло. Существует множество устройств CE 5.0 и более ранних версий, которые по-прежнему неправильно рассчитывают даты изменения летнего времени в США из-за этого.

Решение состоит в том, чтобы обновить устройство с помощью встроенной ОС с правильными определениями.

Теперь, если вы видите проблему, когда вы устанавливаете 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 / TZ. Мы использовали ОС для хранения GMT и ничего больше, затем сделали все смещения вручную. Продукт продается несколькими курьерами, покрывающими несколько часовых поясов, и мы не слышали о проблемах (и, поскольку это время, любые проблемы со временем станут очевидными очень быстро).

...