Здравствуйте, Аноним, Вы писали:

А>1. Почему два GMT+0, один из которых на самом деле +1? Почему GMT +3 (Moscow) на деле +4? Иными словами, что это за формат хранения даты?

Вы учли переход на летнее/зимнее время? Вообще тупость хранить в базе время в локальном формате, так делают только уроды. В базе должно быть время по гринвичу и точка.

Здравствуйте, SE, Вы писали:

0K>>Вы учли переход на летнее/зимнее время? Вообще тупость хранить в базе время в локальном формате, так делают только уроды. В базе должно быть время по гринвичу и точка.

SE>Вообще тупость отсчитывать время в GMT, так делают только уроды. В базе должно быть время UTC и точка.
Вообще тупость хранить время. Время нужно тратить и точка!

Здравствуйте, vmpire, Вы писали:

V>>>В общем, единственное, что нужно сделать, это как-то связать идентификаторы таймзон с инстансом класса TimeZoneInfo, а дальше уже делать с ним всё, что нужно. Простого способа связать я сходу не знаю, но набить 50 соответствий в принципе можно и руками.
А>>Соответствий между числами и строковым id, используемым в TimeZoneInfo.FindSystemTimeZoneById()?
V>Например так.
V>Хотя, с них станется быть локализованными, что усложняет задачу.
V>Если это так, то можно использовать их индекс (который DWORD в Registry) в качестве идентификатора

MSDN явно оговаривает, что StandardName — локализованы, а про Id такого нет. Да и было бы глупо, если бы так было.

Проблема в другом. Результат такого кода:

var zones = TimeZoneInfo.GetSystemTimeZones();
Console.WriteLine("The local system has the following {0} time zones", zones.Count);
foreach (TimeZoneInfo zone in zones)
{
    Console.WriteLine(zone.Id);
}

я вывел в левую колонку. А таблицу отсюда (http://msdn.microsoft.com/en-us/library/ms988620(EXCHG.65).aspx) — в правую. Называется, зачем я прогуливал географию. Чувствую, полдня уйдет на эту херню — синхронизацию левой и правой колонок.

Советы, как сопоставить малой кровью, с благодарностью принимаются.

UTC                (UTC) Universal Coordinated Time cdoUTC 0 
GMT Standard Time                (GMT) Casablanca, Monrovia cdoMonrovia 31 
Greenwich Standard Time                (GMT) Greenwich Mean Time: Dublin, Edinburgh, Lisbon, London cdoLisbon 2 
W. Europe Standard Time                (GMT) Greenwich Mean Time; Dublin, Edinburgh, London cdoGMT 1 
Central Europe Standard Time                (GMT+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna cdoBerlin 4 
Romance Standard Time                (GMT+01:00) Belgrade, Pozsony, Budapest, Ljubljana, Prague cdoPrague 6 
Central European Standard Time                (GMT+01:00) Brussels, Copenhagen, Madrid, Paris cdoParis 3 
W. Central Africa Standard Time                (GMT+01:00) Paris, Madrid, Brussels, Copenhagen cdoParis 3 
Jordan Standard Time                (GMT+01:00) Prague, Central Europe cdoPrague 6 
GTB Standard Time                (GMT+01:00) Sarajevo, Skopje, Sofija, Vilnius, Warsaw, Zagreb cdoSarajevo 2 
Middle East Standard Time                (GMT+01:00) West Central Africa cdoWestCentralAfrica 69 
Egypt Standard Time                (GMT+02:00) Athens, Istanbul, Minsk cdoAthens 7 
Syria Standard Time                (GMT+02:00) Bucharest cdoEasternEurope 5 
South Africa Standard Time                (GMT+02:00) Cairo cdoCairo 49 
FLE Standard Time                (GMT+02:00) Harare, Pretoria cdoHarare 50 
Israel Standard Time                (GMT+02:00) Helsinki, Riga, Tallinn cdoHelsinki 59 
E. Europe Standard Time                (GMT+02:00) Israel, Jerusalem Standard Time cdoIsrael 27 
Namibia Standard Time                (GMT+03:00) Baghdad cdoBaghdad 26 
Arabic Standard Time                (GMT+03:00) Arab, Kuwait, Riyadh cdoArab 74 
Arab Standard Time                (GMT+03:00) Moscow, St. Petersburg, Volgograd cdoMoscow 51 
Russian Standard Time                (GMT+03:00) East Africa, Nairobi cdoEastAfrica 56 
E. Africa Standard Time                (GMT+03:30) Tehran cdoTehran 25 
Iran Standard Time                (GMT+04:00) Abu Dhabi, Muscat cdoAbuDhabi 24 
Arabian Standard Time                (GMT+04:00) Baku, Tbilisi, Yerevan cdoCaucasus 54 
Azerbaijan Standard Time                (GMT+04:30) Kabul cdoKabul 48 
Mauritius Standard Time                (GMT+05:00) Ekaterinburg cdoEkaterinburg 58 
Georgian Standard Time                (GMT+05:00) Islamabad, Karachi, Tashkent cdoIslamabad 47 
Caucasus Standard Time                (GMT+05:30) Kolkata, Chennai, Mumbai, New Delhi, India Standard Time cdoBombay 23 
Afghanistan Standard Time                (GMT+05:45) Kathmandu, Nepal cdoNepal 62 
Ekaterinburg Standard Time                (GMT+06:00) Almaty, Novosibirsk, North Central Asia cdoAlmaty 46 
Pakistan Standard Time                (GMT+06:00) Astana, Dhaka cdoDhaka 71 
West Asia Standard Time                (GMT+06:00) Sri Jayawardenepura, Sri Lanka cdoSriLanka 66 
India Standard Time                (GMT+06:30) Rangoon cdoRangoon 61 
Sri Lanka Standard Time                (GMT+07:00) Bangkok, Hanoi, Jakarta cdoBangkok 22 
Nepal Standard Time                (GMT+07:00) Krasnoyarsk cdoKrasnoyarsk 64 
Central Asia Standard Time                (GMT+08:00) Beijing, Chongqing, Hong Kong SAR, Urumqi cdoBeijing 45 
Bangladesh Standard Time                (GMT+08:00) Irkutsk, Ulaan Bataar cdoIrkutsk 63 
N. Central Asia Standard Time                (GMT+08:00) Kuala Lumpur, Singapore cdoSingapore 21 
Myanmar Standard Time                (GMT+08:00) Perth, Western Australia cdoPerth 73 
SE Asia Standard Time                (GMT+08:00) Taipei cdoTaipei 75 
North Asia Standard Time                (GMT+09:00) Osaka, Sapporo, Tokyo cdoTokyo 20 
China Standard Time                (GMT+09:00) Seoul, Korea Standard time cdoSeoul 72) 
North Asia East Standard Time                (GMT+09:00) Yakutsk cdoYakutsk 70 
Singapore Standard Time                (GMT+09:30) Adelaide, Central Australia cdoAdelaide 19 
W. Australia Standard Time                (GMT+09:30) Darwin cdoDarwin 44 
Taipei Standard Time                (GMT+10:00) Brisbane, East Australia cdoBrisbane 18 
Ulaanbaatar Standard Time                (GMT+10:00) Canberra, Melbourne, Sydney, Hobart (year 2000 only) cdoSydney 76 
Tokyo Standard Time                (GMT+10:00) Guam, Port Moresby cdoGuam 43 
Korea Standard Time                (GMT+10:00) Hobart, Tasmania cdoHobart 42 
Yakutsk Standard Time                (GMT+10:00) Vladivostok cdoVladivostock 68 
Cen. Australia Standard Time                (GMT+11:00) Magadan, Solomon Is., New Caledonia cdoMagadan 41 
AUS Central Standard Time                (GMT+12:00) Auckland, Wellington cdoWellington 17 
E. Australia Standard Time                (GMT+12:00) Fiji Islands, Kamchatka, Marshall Is. cdoFiji 40 
AUS Eastern Standard Time                (GMT+13:00) Nuku'alofa, Tonga cdoTonga 67 
West Pacific Standard Time                (GMT-01:00) Azores cdoAzores 29 
Tasmania Standard Time                (GMT-01:00) Cape Verde Is. cdoCapeVerde 53 
Vladivostok Standard Time                (GMT-02:00) Mid-Atlantic cdoMidAtlantic 30 
Central Pacific Standard Time                (GMT-03:00) Brasilia cdoBrasilia 8 
New Zealand Standard Time                (GMT-03:00) Buenos Aires, Georgetown cdoBuenosAires 32 
UTC+12                (GMT-03:00) Greenland cdoGreenland 60 
Fiji Standard Time                (GMT-03:30) Newfoundland cdoNewfoundland 28 
Kamchatka Standard Time                (GMT-04:00) Atlantic Time (Canada) cdoAtlanticCanada 9 
Tonga Standard Time                (GMT-04:00) Caracas, La Paz cdoCaracas 33 
Azores Standard Time                (GMT-04:00) Santiago cdoSantiago 65 
Cape Verde Standard Time                (GMT-05:00) Bogota, Lima, Quito cdoBogota 35 
UTC-02                (GMT-05:00) Eastern Time (US & Canada) cdoEastern 10 
Mid-Atlantic Standard Time                (GMT-05:00) Indiana (East) cdoIndiana 34 
E. South America Standard Time                (GMT-06:00) Central America cdoCentralAmerica 55 
Argentina Standard Time                (GMT-06:00) Central Time (US & Canada) cdoCentral 11 
SA Eastern Standard Time                (GMT-06:00) Mexico City, Tegucigalpa cdoMexicoCity 37 
Greenland Standard Time                (GMT-06:00) Saskatchewan cdoSaskatchewan 36 
Montevideo Standard Time                (GMT-07:00) Arizona cdoArizona 38 
Newfoundland Standard Time                (GMT-07:00) Mountain Time (US & Canada) cdoMountain 12 
Paraguay Standard Time                (GMT-08:00) Pacific Time (US & Canada); Tijuana cdoPacific 13 
Atlantic Standard Time                (GMT-09:00) Alaska cdoAlaska 14 
Central Brazilian Standard Time                (GMT-10:00) Hawaii cdoHawaii 15 
SA Western Standard Time                (GMT-11:00) Midway Island, Samoa cdoMidwayIsland 16 
Pacific SA Standard Time                (GMT-12:00) Eniwetok, Kwajalein, Dateline Time 
Venezuela Standard Time                
SA Pacific Standard Time                
Eastern Standard Time                
US Eastern Standard Time                
Central America Standard Time                
Central Standard Time                
Central Standard Time (Mexico)                
Canada Central Standard Time                
US Mountain Standard Time                
Mountain Standard Time (Mexico)                
Mountain Standard Time                
Pacific Standard Time (Mexico)                
Pacific Standard Time                
Alaskan Standard Time                
Hawaiian Standard Time                
UTC-11                
Samoa Standard Time                
Dateline Standard Time

В БД хранится дата в колонке типа datetime в некотором непонятном формате, и к ней — поправка под названием TimeZone в виде числа.

Опытным путем установлено, что:

1. При выборе в UI часового пояса "GMT (Casablanka, Monrovia, Reykjavik)" (типа, GMT+0, надо полагать), время выводится на форму так, как оно хранится в базе (по крайней мере, отображается SQL SMS), при этом в БД записывается TimeZone == 31.
2. При выборе в UI часового пояса "GMT (Greenwich Mean Time: Dublin, Edinburgh)" (тоже GMT+0???), время выводится на форму со смещением на час вперед, по сравнению с тем, как оно хранится в базе, при этом в БД записывается TimeZone == 2.
3. При выборе в UI часового пояса "GMT +3 (Moscow)", время выводится на форму со смещением на 4 часа вперед, по сравнению с тем, как оно хранится в базе, при этом в БД записывается TimeZone == 51.

Вопросы:

1. Почему два GMT+0, один из которых на самом деле +1? Почему GMT +3 (Moscow) на деле +4? Иными словами, что это за формат хранения даты?
2. Как кодируется в этой системе TimeZone? 2, 31, 51 — никакого намека на +n.

Что интересует в конечном итоге, это как имея инстансы DateTime dt и int timeZone получить строку (например, с помощью .ToString("d")). Но с этим я и сам справлюсь, если будут ответы на вопросы 1 и 2.

летнее и зимнее время — это одна зона времени, но с разным временем. Если у вас Windows система, посмотрите в реестре как зоны времени пишутся, например зону Moscow
А вот цифры — это какое-то доморощеное произведение искусства, ищите, где у вас в программе или может в базе лежит табличка с переводом.
Я сомневаюсь, что может быть где-то стандартный список с цифирьками, зоны времени же еще и меняются. Вот придумал Медведев, что у нас их многовато — и Microsoft вынужден обновление к Windows выпускать с новым списком...
В общем случае, для зон времени хранятся названия и сдвиг от GMT, еще в какой-нибудь форме записывается, по каким правилам осуществляется переход на зимнее/летнее время, плюс иногда хранятся исторические зоны времени, если что-то законодательно менялось. Поэтому, если у вас не дай бог в базе есть Парагвай, то все совсем плохо, потому что там каждый год переход по-разному происходит.
А уж каждая программа в силу своей испорченности пытается имеющуюся информацию трактовать. Вот, например, почитайте: http://blogs.msdn.com/b/bclteam/archive/2007/06/07/exploring-windows-time-zones-with-system-timezoneinfo-josh-free.aspx

И это не только в Windows так, iCal спецификация на этот счет примерно так же мутно выглядит.

Здравствуйте, Аноним, Вы писали:

А>В БД хранится дата в колонке типа datetime в некотором непонятном формате, и к ней — поправка под названием TimeZone в виде числа.

А>Опытным путем установлено, что:

А>1. При выборе в UI часового пояса "GMT (Casablanka, Monrovia, Reykjavik)" (типа, GMT+0, надо полагать)
Точнее, GMT+0 без перехода на летнее время
А>, время выводится на форму так, как оно хранится в базе (по крайней мере, отображается SQL SMS), при этом в БД записывается TimeZone == 31.
А>2. При выборе в UI часового пояса "GMT (Greenwich Mean Time: Dublin, Edinburgh)" (тоже GMT+0???)
Точнее, GMT+0 с переходом на летнее время
А>, время выводится на форму со смещением на час вперед, по сравнению с тем, как оно хранится в базе, при этом в БД записывается TimeZone == 2.
А>3. При выборе в UI часового пояса "GMT +3 (Moscow)", время выводится на форму со смещением на 4 часа вперед, по сравнению с тем, как оно хранится в базе, при этом в БД записывается TimeZone == 51.
Опять же, учтён переход на летнее время, как уже указал 0K

А>Вопросы:

А>1. Почему два GMT+0, один из которых на самом деле +1?
Это разные таймзоны. Время в них совпадет только без учёта летнего время
А> Почему GMT +3 (Moscow) на деле +4? Иными словами, что это за формат хранения даты?
Летнее время

А>2. Как кодируется в этой системе TimeZone? 2, 31, 51 — никакого намека на +n.
Это просто коды таймзон, к смещениям отношения не имеют. Очень похожи на коды CDO:

enum CdoTimeZoneId
    {    cdoUTC    = 0,
    cdoGMT    = 1,
    cdoSarajevo    = 2,
    cdoParis    = 3,
    cdoBerlin    = 4,
    cdoEasternEurope    = 5,
    cdoPrague    = 6,
    cdoAthens    = 7,
    cdoBrasilia    = 8,
    cdoAtlanticCanada    = 9,
    cdoEastern    = 10,
    cdoCentral    = 11,
    cdoMountain    = 12,
    cdoPacific    = 13,
    cdoAlaska    = 14,
    cdoHawaii    = 15,
    cdoMidwayIsland    = 16,
    cdoWellington    = 17,
    cdoBrisbane    = 18,
    cdoAdelaide    = 19,
    cdoTokyo    = 20,
    cdoSingapore    = 21,
    cdoBangkok    = 22,
    cdoBombay    = 23,
    cdoAbuDhabi    = 24,
    cdoTehran    = 25,
    cdoBaghdad    = 26,
    cdoIsrael    = 27,
    cdoNewfoundland    = 28,
    cdoAzores    = 29,
    cdoMidAtlantic    = 30,
    cdoMonrovia    = 31,
    cdoBuenosAires    = 32,
    cdoCaracas    = 33,
    cdoIndiana    = 34,
    cdoBogota    = 35,
    cdoSaskatchewan    = 36,
    cdoMexicoCity    = 37,
    cdoArizona    = 38,
    cdoEniwetok    = 39,
    cdoFiji    = 40,
    cdoMagadan    = 41,
    cdoHobart    = 42,
    cdoGuam    = 43,
    cdoDarwin    = 44,
    cdoBeijing    = 45,
    cdoAlmaty    = 46,
    cdoIslamabad    = 47,
    cdoKabul    = 48,
    cdoCairo    = 49,
    cdoHarare    = 50,
    cdoMoscow    = 51,
    cdoFloating    = 52,
    cdoCapeVerde    = 53,
    cdoCaucasus    = 54,
    cdoCentralAmerica    = 55,
    cdoEastAfrica    = 56,
    cdoMelbourne    = 57,
    cdoEkaterinburg    = 58,
    cdoHelsinki    = 59,
    cdoGreenland    = 60,
    cdoRangoon    = 61,
    cdoNepal    = 62,
    cdoIrkutsk    = 63,
    cdoKrasnoyarsk    = 64,
    cdoSantiago    = 65,
    cdoSriLanka    = 66,
    cdoTonga    = 67,
    cdoVladivostok    = 68,
    cdoWestCentralAfrica    = 69,
    cdoYakutsk    = 70,
    cdoDhaka    = 71,
    cdoSeoul    = 72,
    cdoPerth    = 73,
    cdoArab    = 74,
    cdoTaipei    = 75,
    cdoSydney2000    = 76,
    cdoChihuahua    = 77,
    cdoCanberraCommonwealthGames2006    = 78,
    cdoAdelaideCommonwealthGames2006    = 79,
    cdoHobartCommonwealthGames2006    = 80,
    cdoTijuana    = 81,
    cdoInvalidTimeZone    = 82
    }     CdoTimeZoneId;

действительно похоже. Только с летним временем как-то все мутно, оно же тут вообще не фигурирует.

Здравствуйте, notacat, Вы писали:

N>действительно похоже. Только с летним временем как-то все мутно, оно же тут вообще не фигурирует.
Ничего не мутно. Сейчас лето — вот оно и прибавляется.
В идентификаторе таймзоны оно не фигурирует, так как с летним временем или без — это одна и та же таймзона.
Просто для разного времени года смещение разное.

N>>действительно похоже. Только с летним временем как-то все мутно, оно же тут вообще не фигурирует.
V>Ничего не мутно. Сейчас лето — вот оно и прибавляется.
Это не прибавляет ясности в вопросе, как из DateTime и номера зоны времени получить правильную строку для любой зоны времени, а не для локальной. Это локально у нас летнее время, а где-то может вообще перехода нет, или DateTime из базы представляет собой не сегодняшний день, а что-нибудь типа 1 января.

Здравствуйте, notacat, Вы писали:

N>>>действительно похоже. Только с летним временем как-то все мутно, оно же тут вообще не фигурирует.
V>>Ничего не мутно. Сейчас лето — вот оно и прибавляется.
N>Это не прибавляет ясности в вопросе, как из DateTime и номера зоны времени получить правильную строку для любой зоны времени, а не для локальной.
Смотря что понимать под "правильной строкой". Строкой чего?

N> Это локально у нас летнее время, а где-то может вообще перехода нет,
Тогда это другая таймзона

N> DateTime из базы представляет собой не сегодняшний день, а что-нибудь типа 1 января.
Тогда для него будет зимнее смещение

В общем, единственное, что нужно сделать, это как-то связать идентификаторы таймзон с инстансом класса TimeZoneInfo, а дальше уже делать с ним всё, что нужно. Простого способа связать я сходу не знаю, но набить 50 соответствий в принципе можно и руками.

Здравствуйте, vmpire, Вы писали:

V>В общем, единственное, что нужно сделать, это как-то связать идентификаторы таймзон с инстансом класса TimeZoneInfo, а дальше уже делать с ним всё, что нужно. Простого способа связать я сходу не знаю, но набить 50 соответствий в принципе можно и руками.

Соответствий между числами и строковым id, используемым в TimeZoneInfo.FindSystemTimeZoneById()?

Здравствуйте, 0K, Вы писали:

0K>Вы учли переход на летнее/зимнее время? Вообще тупость хранить в базе время в локальном формате, так делают только уроды. В базе должно быть время по гринвичу и точка.

Вообще тупость отсчитывать время в GMT, так делают только уроды. В базе должно быть время UTC и точка.

P.S. В чем же разница между GMT и UTC, и почему именно UTC, погуглите сами или почитайте тут
http://en.wikipedia.org/wiki/Greenwich_Mean_Time
http://en.wikipedia.org/wiki/UTC

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, vmpire, Вы писали:

V>>В общем, единственное, что нужно сделать, это как-то связать идентификаторы таймзон с инстансом класса TimeZoneInfo, а дальше уже делать с ним всё, что нужно. Простого способа связать я сходу не знаю, но набить 50 соответствий в принципе можно и руками.

А>Соответствий между числами и строковым id, используемым в TimeZoneInfo.FindSystemTimeZoneById()?
Например так.
Хотя, с них станется быть локализованными, что усложняет задачу.
Если это так, то можно использовать их индекс (который DWORD в Registry) в качестве идентификатора

V>Если это так, то можно использовать их индекс (который DWORD в Registry) в качестве идентификатора
у меня в реестре у зон времени вообще нет DWORD параметров (Виста)

|| Unix.

V>>Если это так, то можно использовать их индекс (который DWORD в Registry) в качестве идентификатора
N>у меня в реестре у зон времени вообще нет DWORD параметров (Виста)
и кстати, в моем реестре 97 разных зон времени, не 50

Здравствуйте, notacat, Вы писали:

V>>>Если это так, то можно использовать их индекс (который DWORD в Registry) в качестве идентификатора
N>>у меня в реестре у зон времени вообще нет DWORD параметров (Виста)
N>и кстати, в моем реестре 97 разных зон времени, не 50
Ну, значит часть в енуме не используется

Здравствуйте, notacat, Вы писали:

V>>Если это так, то можно использовать их индекс (который DWORD в Registry) в качестве идентификатора
N>у меня в реестре у зон времени вообще нет DWORD параметров (Виста)
Тогда не знаю. Возможно, Id всё-таки не локализуемое.

Вот придумал Медведев, что у нас их многовато — и Microsoft вынужден обновление к Windows выпускать с новым списком...
Вам вааще с Медведевым повезло — вот было бы у вас типа дерьмократическое чмо типа Юща или Явлинского или еще кого бы то нибыло, пиндосы бы васм время переводили — у вас бы его уже не было )))))

кто здесь?

Здравствуйте, Аноним, Вы писали:

Вот это облегчает дело:

А>

А>var zones = TimeZoneInfo.GetSystemTimeZones();
А>Console.WriteLine("The local system has the following {0} time zones", zones.Count);
А>foreach (TimeZoneInfo zone in zones)
А>{
А>    Console.WriteLine(zone.DisplayName);
А>}
А>

SE>Вообще тупость отсчитывать время в GMT, так делают только уроды. В базе должно быть время UTC и точка.

После чего иметь долгий и упорный трах с разными grid control и их фильтрами.
Пользователи-то не в UTC думают.

Здравствуйте, Nikolay_P_I, Вы писали:

SE>>Вообще тупость отсчитывать время в GMT, так делают только уроды. В базе должно быть время UTC и точка.

Вообще-то мой сарказм был направлен в сторону безапеляционного заявления 0K.
Но, раз пошла такая пьянка

N_P>После чего иметь долгий и упорный трах с разными grid control и их фильтрами.
N_P>Пользователи-то не в UTC думают.

Писал как-то приложение для распределенных по всему миру коллцентров. К примеру потребители в Британии, Австралии и России, коллцентры в Индии, Украине и Казахстане, а заказчики услуг коллцентра в Нью-Йорке.
Написали класс для биндинга с приведением UTC к локальному времени юзера, который на сайт залогинился, и все отлично работало.

А как раз долгий и упорный трах был в начале, когда была предпринята попытка не пользоваться этим самым UTC.

Кстати, в Австралии три часовых пояса, причем один из них отличается от других на полчаса и, если не изменяет память, действует только в одном городе. Помню, стоило больших трудов убедить заказчиков, что лучше юзверам предоставить возможность самим таймзону свою выставить.

К следующему вашему посту — Display Name тоже локализовано, так что на разных системах будет бардак.

1. определитесь с тем, где ваш код будет работать, на одной машине, для которой можно предсказать хотя бы язык, или на любой непредсказуемой. Если только на англоязычной — то можно посравнивать DisplayName и табличку Cdo по названиям зон. Если система не английская — то сравнивать можно только сдвиг (GMT+01:00). Потому что не в английских системах DisplayName выглядит так: "(GMT+03:00) Волгоград, Москва, Санкт-Петербург"

2. нужны ли вам те зоны, которые вообще есть, но в CDO не числятся. И насколько чем можно пренебречь. Может устроит простой анализ сдвига относительно GMT.

3. может быть у вашей программы есть возможность доступа к какому-нибудь серверу Exchange. Если да, можно попробовать этим воспользоваться для перевода.

4. на StackOverflow вы вопрос задали? Если нет, подпишитесь на ответы

Здравствуйте, Nikolay_P_I, Вы писали:

SE>>Вообще тупость отсчитывать время в GMT, так делают только уроды. В базе должно быть время UTC и точка.

N_P>После чего иметь долгий и упорный трах с разными grid control и их фильтрами.
N_P>Пользователи-то не в UTC думают.
ага, они думают в локальном времени сервера?

Здравствуйте, notacat, Вы писали:

N>К следующему вашему посту — Display Name тоже локализовано, так что на разных системах будет бардак.

N>1. определитесь с тем, где ваш код будет работать, на одной машине, для которой можно предсказать хотя бы язык, или на любой непредсказуемой. Если только на англоязычной — то можно посравнивать DisplayName и табличку Cdo по названиям зон. Если система не английская — то сравнивать можно только сдвиг (GMT+01:00). Потому что не в английских системах DisplayName выглядит так: "(GMT+03:00) Волгоград, Москва, Санкт-Петербург"

N>2. нужны ли вам те зоны, которые вообще есть, но в CDO не числятся. И насколько чем можно пренебречь. Может устроит простой анализ сдвига относительно GMT.

Простой анализ сдвига не учтёт переходы на летнее/зимнее время. Я так понимаю, он хочет задать соответствие cdo с Id часового пояса при разработке (в конфиге например). Тогда неважно где будет работать код и какой там будет язык.

Здравствуйте, SE, Вы писали:


SE>Писал как-то приложение для распределенных по всему миру коллцентров. К примеру потребители в Британии, Австралии и России, коллцентры в Индии, Украине и Казахстане, а заказчики услуг коллцентра в Нью-Йорке.
SE>Написали класс для биндинга с приведением UTC к локальному времени юзера, который на сайт залогинился, и все отлично работало.
и они считали доли секунды (я так понял основное отличие GMT от UTC) ?

Здравствуйте, notacat, Вы писали:

N>К следующему вашему посту — Display Name тоже локализовано, так что на разных системах будет бардак.

Я имел в виду, что сопоставить колонки легче, глядя на Display Name (локализуемый, но локализованный или нет — не важно, коль скоро вы читаете на обоих языках), как добавку к Id. В коде же, как писалось ранее, сопоставить номер CDO и нелокализуемый Id, а при написании мапы (или, скорее, плоского массива Id, где номер CDO — индекс) — подглядывать в Display Name.

Дело в том, что сопоставить не так просто. Ладно, что в MSDN два вхождения на 6-ку в CDO, оба записанные по-разному. Это лишь тест на внимательность, тыксызыть. Но вот вопрос: (GMT+12:00) Fiji Islands, Kamchatka, Marshall Is. cdoFiji 40 — это кто, Фиджи или Петропавловск? У меня в WinServer2K8 это разные TimeZoneInfo. А что на 2K3 будет? Писец, одним словом.

Но пока я не догадался вывести еще и Display Name, для себя, все было еще песцовее. Надо было вооружиться атласом и сверять столицы.

N>1. определитесь с тем, где ваш код будет работать, на одной машине, для которой можно предсказать хотя бы язык, или на любой непредсказуемой. Если только на англоязычной — то можно посравнивать DisplayName и табличку Cdo по названиям зон. Если система не английская — то сравнивать можно только сдвиг (GMT+01:00). Потому что не в английских системах DisplayName выглядит так: "(GMT+03:00) Волгоград, Москва, Санкт-Петербург"

Как уже говорилось, DisplayName нужен программисту для ручного написания мапы "CDO — Id" или массива Id, выстроенного в порядке кодов CDO.

N>2. нужны ли вам те зоны, которые вообще есть, но в CDO не числятся. И насколько чем можно пренебречь. Может устроит простой анализ сдвига относительно GMT.

Не нужны. Простой анализ сдвига не устроит, поскольку софтина, которая пишет в базу, умеет отличать зимнее время от летнего. А мой плагин к ней не должен расходиться в показаниях с главным интерфейсом. Хотя, учитывая вопрос типа заданного выше, ошибки неизбежны

N>4. на StackOverflow вы вопрос задали? Если нет, подпишитесь на ответы

http://stackoverflow.com/questions/3826798/cdotimezoneid-timezoneinfo

Это я написал, когда меня еще не осенило подсмотреть в DisplayName, а потом дописал UPDATE.

Здравствуйте, SE, Вы писали:

SE>Кстати, в Австралии три часовых пояса, причем один из них отличается от других на полчаса и, если не изменяет память, действует только в одном городе. Помню, стоило больших трудов убедить заказчиков, что лучше юзверам предоставить возможность самим таймзону свою выставить.
Это частный случай проблемы неудачного представления данных. Ровно такой же случай был в городе Редмонд Вашингтонской области: http://blogs.msdn.com/b/ruericlippert/archive/2009/06/01/9698783.aspx

Здравствуйте, 0K, Вы писали:

0K>Вообще тупость хранить в базе время в локальном формате, так делают только уроды. В базе должно быть время по гринвичу и точка.

Так в базе оно не хранится в локальном формате. Скорее всего, в UTC. А к нему хранится код таймзоны для перевода в локальный формат при отображении в GUI. Что-то плохо у меня с объяснятельными способностями стало.

А>Дело в том, что сопоставить не так просто. Ладно, что в MSDN два вхождения на 6-ку в CDO, оба записанные по-разному. Это лишь тест на внимательность, тыксызыть. Но вот вопрос: (GMT+12:00) Fiji Islands, Kamchatka, Marshall Is. cdoFiji 40 — это кто, Фиджи или Петропавловск? У меня в WinServer2K8 это разные TimeZoneInfo. А что на 2K3 будет? Писец, одним словом.
Фиджи и Петропавловск находятся в разных государствах. Поэтому они могут поменяться независимо друг от друга. Так же как Екатеринбург, Исламабад и Карачи. GMT+5 одинаково, но вот в Исламабаде в этом году летнего времени нету. Ну и так далее.
Вот, кстати, интересный сайт с картой на эту тему: http://24timezones.com/ (карта интерактивная)

Здравствуйте, Nikolay_P_I, Вы писали:

SE>>Вообще тупость отсчитывать время в GMT, так делают только уроды. В базе должно быть время UTC и точка.
N_P>После чего иметь долгий и упорный трах с разными grid control и их фильтрами.
N_P>Пользователи-то не в UTC думают.
Вот при выводе куда-нибудь на экран — и форматировать с учётом временной зоны пользователя.

Здравствуйте, cadet354, Вы писали:

C>Здравствуйте, SE, Вы писали:


SE>>Писал как-то приложение для распределенных по всему миру коллцентров. К примеру потребители в Британии, Австралии и России, коллцентры в Индии, Украине и Казахстане, а заказчики услуг коллцентра в Нью-Йорке.
SE>>Написали класс для биндинга с приведением UTC к локальному времени юзера, который на сайт залогинился, и все отлично работало.
C>и они считали доли секунды (я так понял основное отличие GMT от UTC) ?

Наверно все же дело в том, что в .NET куда не плюнь, а методы перевода конвертируют в/из UTC. В тоже время, мест в базовых библиотеках, где упомянут GMT — раз, два и обчелся.

Т.е. разницы по большому счету нет, а есть просто соглашения вроде такого вот:

In casual use, Greenwich Mean Time (GMT) is the same as UTC and UT1. Owing to the ambiguity of whether UTC or UT1 is meant, and because timekeeping laws usually refer to UTC, GMT is avoided in careful writing.

Здравствуйте, Аноним, Вы писали:

static string[] _ZoneIds =
{
    "UTC",
    "GMT Standard Time",
    "GMT Standard Time",
    "Central European Standard Time",
    "Romance Standard Time",
    "W. Europe Standard Time",
    "GTB Standard Time",
    "Central Europe Standard Time",
    "GTB Standard Time",
    "E. South America Standard Time",
    "Atlantic Standard Time",
    "Eastern Standard Time",
    "Central Standard Time",
    "Mountain Standard Time",
    "Pacific Standard Time",
    "Alaskan Standard Time",
    "Hawaiian Standard Time",
    "Samoa Standard Time",
    "New Zealand Standard Time",
    "E. Australia Standard Time",
    "Cen. Australia Standard Time",
    "Tokyo Standard Time",
    "Singapore Standard Time",
    "SE Asia Standard Time",
    "India Standard Time",
    "Arabian Standard Time",
    "Iran Standard Time",
    "Arabic Standard Time",
    "Israel Standard Time",
    "Newfoundland Standard Time",
    "Azores Standard Time",
    "Mid-Atlantic Standard Time",
    "Greenwich Standard Time",
    "Argentina Standard Time",
    "Venezuela Standard Time",
    "US Eastern Standard Time",
    "SA Pacific Standard Time",
    "Canada Central Standard Time",
    "Central Standard Time (Mexico)",
    "US Mountain Standard Time",
    "Dateline Standard Time",
    "Fiji Standard Time",
    "Central Pacific Standard Time",
    "Tasmania Standard Time",
    "West Pacific Standard Time",
    "AUS Central Standard Time",
    "China Standard Time",
    "N. Central Asia Standard Time",
    "Pakistan Standard Time",
    "Afghanistan Standard Time",
    "Egypt Standard Time",
    "South Africa Standard Time",
    "Russian Standard Time",
    "Cape Verde Standard Time",
    "Azerbaijan Standard Time",
    "Central America Standard Time",
    "E. Africa Standard Time",
    "Ekaterinburg Standard Time",
    "FLE Standard Time",
    "Greenland Standard Time",
    "Myanmar Standard Time",
    "Nepal Standard Time",
    "North Asia East Standard Time",
    "North Asia Standard Time",
    "Pacific SA Standard Time",
    "Sri Lanka Standard Time",
    "Tonga Standard Time",
    "Vladivostok Standard Time",
    "W. Central Africa Standard Time",
    "Yakutsk Standard Time",
    "Central Asia Standard Time",
    "Korea Standard Time",
    "W. Australia Standard Time",
    "Arab Standard Time",
    "Taipei Standard Time",
    "AUS Eastern Standard Time",
};

TimeZoneInfo CdoToZoneId(int cdo)
{
    return TimeZoneInfo.FindSystemTimeZoneById(_ZoneIds[cdo]);
}

Здравствуйте, Аноним, Вы писали:

Вот исправленный вариант.

#region Timezones.

        /// <summary>
        /// IDs of timezones, which are counterparts of CDO enum members.
        /// They are sorted in order of according CDO codes increasing.
        /// <seealso cref="http://msdn.microsoft.com/en-us/library/ms988620(EXCHG.65).aspx"/>
        /// </summary>
        private static string[] _ZoneIds =
        {
            "UTC",                        // 0
            "GMT Standard Time",                // 1 Not used. [DB:1] -> "Dateline Standard Time" -> [DB:39].
            "GMT Standard Time",                // 2
            "Romance Standard Time",            // 3
            "W. Europe Standard Time",            // 4
            "GTB Standard Time",                // 5
            "Central Europe Standard Time",            // 6
            "GTB Standard Time",                // 7
            "E. South America Standard Time",        // 8
            "Atlantic Standard Time",            // 9
            "Eastern Standard Time",            // 10
            "Central Standard Time",            // 11
            "Mountain Standard Time",            // 12
            "Pacific Standard Time",            // 13
            "Alaskan Standard Time",            // 14
            "Hawaiian Standard Time",            // 15
            "Samoa Standard Time",                // 16
            "New Zealand Standard Time",            // 17
            "E. Australia Standard Time",            // 18
            "Cen. Australia Standard Time",            // 19
            "Tokyo Standard Time",                // 20
            "Singapore Standard Time",            // 21
            "SE Asia Standard Time",            // 22
            "India Standard Time",                // 23
            "Arabian Standard Time",            // 24
            "Iran Standard Time",                // 25
            "Arabic Standard Time",                // 26
            "Israel Standard Time",                // 27
            "Newfoundland Standard Time",            // 28
            "Azores Standard Time",                // 29
            "Mid-Atlantic Standard Time",            // 30
            "Greenwich Standard Time",            // 31
            "Argentina Standard Time",            // 32
            "Venezuela Standard Time",            // 33
            "US Eastern Standard Time",            // 34
            "SA Pacific Standard Time",            // 35
            "Canada Central Standard Time",            // 36
            "Central Standard Time (Mexico)",        // 37
            "US Mountain Standard Time",            // 38
            "Dateline Standard Time",            // 39
            "Fiji Standard Time",                // 40
            "Central Pacific Standard Time",        // 41
            "Tasmania Standard Time",            // 42
            "West Pacific Standard Time",            // 43
            "AUS Central Standard Time",            // 44
            "China Standard Time",                // 45
            "N. Central Asia Standard Time",        // 46
            "Pakistan Standard Time",            // 47
            "Afghanistan Standard Time",            // 48
            "Egypt Standard Time",                // 49
            "South Africa Standard Time",            // 50
            "Russian Standard Time",            // 51
            "UTC",                        // 52 No according CDO code :(.
            "Cape Verde Standard Time",            // 53
            "Azerbaijan Standard Time",            // 54
            "Central America Standard Time",        // 55
            "E. Africa Standard Time",            // 56
            "UTC",                        // 57 No according CDO code :(.
            "Ekaterinburg Standard Time",            // 58
            "FLE Standard Time",                // 59
            "Greenland Standard Time",            // 60
            "Myanmar Standard Time",            // 61
            "Nepal Standard Time",                // 62
            "North Asia East Standard Time",        // 63
            "North Asia Standard Time",            // 64
            "Pacific SA Standard Time",            // 65
            "Sri Lanka Standard Time",            // 66
            "Tonga Standard Time",                // 67
            "Vladivostok Standard Time",            // 68
            "W. Central Africa Standard Time",        // 69
            "Yakutsk Standard Time",            // 70
            "Central Asia Standard Time",            // 71
            "Korea Standard Time",                // 72
            "W. Australia Standard Time",            // 73
            "Arab Standard Time",                // 74
            "Taipei Standard Time",                // 75
            "AUS Eastern Standard Time",            // 76
        };

        /// <summary>
        /// Converts CDO code into TimeZoneInfo's id.
        /// </summary>
        /// <param name="cdo">CDO code from the DB. It should be between 0 and _ZoneIds.Length - 1.</param>
        /// <returns>TimeZoneInfo non-localizable id, based on CDO code.</returns>
        static private string CdoToZoneId(uint cdo)
        {
            return _ZoneIds[cdo];
        }

        /// <summary>
        /// Checks, if CDO code is in range or not.
        /// </summary>
        /// <param name="cdo">CDO code to be tested.</param>
        /// <returns>True, if CDO code has a counterpart in TimeZoneInfo ids array. False otherwise.</returns>
        static public bool IsCdoCodeAllowed(uint cdo)
        {
            return cdo > 0 && cdo < _ZoneIds.Length;
        }

#endregion

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, SE, Вы писали:

SE>>Кстати, в Австралии три часовых пояса, причем один из них отличается от других на полчаса и, если не изменяет память, действует только в одном городе. Помню, стоило больших трудов убедить заказчиков, что лучше юзверам предоставить возможность самим таймзону свою выставить.
S>Это частный случай проблемы неудачного представления данных. Ровно такой же случай был в городе Редмонд Вашингтонской области: http://blogs.msdn.com/b/ruericlippert/archive/2009/06/01/9698783.aspx

Интересная история, нашим решением как раз и стало полное переосмысление того, как нужно работать с датами, чтобы все свелось к нескольким простым формулам вместо нагромождения непонятных вычислений, похожих на те, с которыми столкнулся автор.
К слову, оказалось, что это удобно в случае коммандировок, в которых некоторые на ноутбуках локальное время не переводят, потому что хотят "жить" по часам главного офиса. А вот расписания им подавай в локальном времени, вроде нотификаций "нужно подтвердить не позднее чем через 3 часа".

Здравствуйте, SE, Вы писали:

SE>Интересная история, нашим решением как раз и стало полное переосмысление того, как нужно работать с датами, чтобы все свелось к нескольким простым формулам вместо нагромождения непонятных вычислений, похожих на те, с которыми столкнулся автор.
SE>К слову, оказалось, что это удобно в случае коммандировок, в которых некоторые на ноутбуках локальное время не переводят, потому что хотят "жить" по часам главного офиса. А вот расписания им подавай в локальном времени, вроде
нотификаций "нужно подтвердить не позднее чем через 3 часа".
Ну вот, в частности, мой HTC HD2 постоянно промахивается с часовым поясом. Поэтому сейчас у меня он врёт на 1 час. Тем не менее, встречам это не мешает — они тоже съезжают куда надо. Это может стать проблемой, если я стану планировать встречи на нём.