А>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);
А>}
А>
Здравствуйте, 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 думают.
ага, они думают в локальном времени сервера?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[10]: #$@#%$^%!!!!!
От:
Аноним
Дата:
30.09.10 10:25
Оценка:
Здравствуйте, notacat, Вы писали:
N>К следующему вашему посту — Display Name тоже локализовано, так что на разных системах будет бардак.
N>1. определитесь с тем, где ваш код будет работать, на одной машине, для которой можно предсказать хотя бы язык, или на любой непредсказуемой. Если только на англоязычной — то можно посравнивать DisplayName и табличку Cdo по названиям зон. Если система не английская — то сравнивать можно только сдвиг (GMT+01:00). Потому что не в английских системах DisplayName выглядит так: "(GMT+03:00) Волгоград, Москва, Санкт-Петербург"
N>2. нужны ли вам те зоны, которые вообще есть, но в CDO не числятся. И насколько чем можно пренебречь. Может устроит простой анализ сдвига относительно GMT.
Простой анализ сдвига не учтёт переходы на летнее/зимнее время. Я так понимаю, он хочет задать соответствие cdo с Id часового пояса при разработке (в конфиге например). Тогда неважно где будет работать код и какой там будет язык.
SE>Писал как-то приложение для распределенных по всему миру коллцентров. К примеру потребители в Британии, Австралии и России, коллцентры в Индии, Украине и Казахстане, а заказчики услуг коллцентра в Нью-Йорке. SE>Написали класс для биндинга с приведением UTC к локальному времени юзера, который на сайт залогинился, и все отлично работало.
и они считали доли секунды (я так понял основное отличие GMT от UTC) ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[10]: #$@#%$^%!!!!!
От:
Аноним
Дата:
30.09.10 10:52
Оценка:
Здравствуйте, 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 вы вопрос задали? Если нет, подпишитесь на ответы
Здравствуйте, SE, Вы писали:
SE>Кстати, в Австралии три часовых пояса, причем один из них отличается от других на полчаса и, если не изменяет память, действует только в одном городе. Помню, стоило больших трудов убедить заказчиков, что лучше юзверам предоставить возможность самим таймзону свою выставить.
Это частный случай проблемы неудачного представления данных. Ровно такой же случай был в городе Редмонд Вашингтонской области: http://blogs.msdn.com/b/ruericlippert/archive/2009/06/01/9698783.aspx
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: Timezone?
От:
Аноним
Дата:
30.09.10 10:58
Оценка:
Здравствуйте, 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.
Re[9]: #$@#%$^%!!!!!
От:
Аноним
Дата:
01.10.10 06:49
Оценка:
Здравствуйте, Аноним, Вы писали:
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]);
}
Re[10]: Исправленный вариант
От:
Аноним
Дата:
03.10.10 20:36
Оценка:
Здравствуйте, Аноним, Вы писали:
Вот исправленный вариант.
#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 час. Тем не менее, встречам это не мешает — они тоже съезжают куда надо. Это может стать проблемой, если я стану планировать встречи на нём.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
