Комментарии 17
DateTime utc = DateTime.UtcNow;Код изначально кривой и писал его человек, не понимающий того, как он работает. Даже выражение DateTime.Now == DateTime.Now будет истинным или ложным в зависимости от точности таймера, отсутствия или наличия переключения контекста потока и погоды на Марсе.
DateTime local = DateTime.Now;
bool mystery = local == utc;
+4
Собсно, прогнал для теста:
$ csharp
Mono C# Shell, type «help;» for help
Enter statements below.
csharp> int t, f; for (int c=0; c<20000; c++) if(DateTime.Now==DateTime.Now) t++; else f++; Console.WriteLine («True:{0}, False: {1}», t, f);
True:19005, False: 995
+5
Например, предположим, что часы не тикнули между вызовами двух свойств в ниже приведенном коде.
+6
Может не DateTime.Now == DateTime.Now, а DateTime.UtcNow == DateTime.Now?
-1
А я-то думал, что придумать что-то хуже стандартных джавовских Date и Calendar нельзя… Оказывается, можно :-)
+3
Если честно…
а) Мозг частично сломан.
б) Чёрт меня дёрнул полезть смотреть про секунду координации. В итоге, как всегда, оказался довольно далеко от точки входа в вики.
в) Узнал для себя довольно много интересного и, вероятно, полезного. Осталось проанализировать.
За перевод спасибо — и статья отлична, и перевод.
а) Мозг частично сломан.
б) Чёрт меня дёрнул полезть смотреть про секунду координации. В итоге, как всегда, оказался довольно далеко от точки входа в вики.
в) Узнал для себя довольно много интересного и, вероятно, полезного. Осталось проанализировать.
За перевод спасибо — и статья отлична, и перевод.
+1
Где тут неоднозначность?
Читаем MSDN по поводу DateTime.Now и DateTime.UtcNow. Видим соответственно в них:
Структура заполняется разными значениями и DateTime.Now == DateTime.UtcNow только в том случае, если локальный часовой пояс — именно UTC. При этом можно свободно конвертировать данные между локальным часовым поясом и UTC: DateTime.ToLocalTime, DateTime.ToUniversalTime. Соответственно всегда будут в true выражения DateTime.Now.ToUniversalTime() == DateTime.UtcTime и DateTime.Now == DateTime.UtcTime.ToLocalTime(). Да и сравнивать лучше через DateTime.Equal() (кстати, у нее примером показан как раз данный случай).
Если же код ведет себя иначе, то это баг и о нем надо сообщить Microsoft.
Читаем MSDN по поводу DateTime.Now и DateTime.UtcNow. Видим соответственно в них:
expressed as the local time
expressed as the Coordinated Universal Time (UTC)
Структура заполняется разными значениями и DateTime.Now == DateTime.UtcNow только в том случае, если локальный часовой пояс — именно UTC. При этом можно свободно конвертировать данные между локальным часовым поясом и UTC: DateTime.ToLocalTime, DateTime.ToUniversalTime. Соответственно всегда будут в true выражения DateTime.Now.ToUniversalTime() == DateTime.UtcTime и DateTime.Now == DateTime.UtcTime.ToLocalTime(). Да и сравнивать лучше через DateTime.Equal() (кстати, у нее примером показан как раз данный случай).
Если же код ведет себя иначе, то это баг и о нем надо сообщить Microsoft.
+1
наконецто ктото занялся вопросом о дате и времени в Windows приложениях
для десктоп приложений чаще всего не принципиально — используется Kind=local и всех делов
но если возникла потребность представления информации в разных часовых поясах (в вебе это наиболее часто), то все не просто плохо, а очень плохо
зону нужно учитывать отдельно, операции с датами сделаны через ж
дату как дату из DateTime получили, но сравнивать как дату с другим DateTime уже не корректно — надо опять доставать проперть Date
но это еще все цветочки
с августа месяца у Windows (не .Net) категорическая проблема с записями часовых поясов
после августовского патча часовые пояса для России закончились 31 декабря 2010 года. попытка преобразования дат раньше 1.01.2011 приводит к ошибкам — летом легко получить +5 для москвы при пересчете через UTC
сейчас этот патч просто откатили!
посмотрите в настройках часового пояса в винде для России (Москва например) — там снова есть возможность перехода на летнее время!
для десктоп приложений чаще всего не принципиально — используется Kind=local и всех делов
но если возникла потребность представления информации в разных часовых поясах (в вебе это наиболее часто), то все не просто плохо, а очень плохо
зону нужно учитывать отдельно, операции с датами сделаны через ж
дату как дату из DateTime получили, но сравнивать как дату с другим DateTime уже не корректно — надо опять доставать проперть Date
но это еще все цветочки
с августа месяца у Windows (не .Net) категорическая проблема с записями часовых поясов
после августовского патча часовые пояса для России закончились 31 декабря 2010 года. попытка преобразования дат раньше 1.01.2011 приводит к ошибкам — летом легко получить +5 для москвы при пересчете через UTC
сейчас этот патч просто откатили!
посмотрите в настройках часового пояса в винде для России (Москва например) — там снова есть возможность перехода на летнее время!
0
Да нормальное API. Проблем, конечно, с датами и временем куча, но эта сложность обусловлена объективной сложностью модели. Нельзя поверх сложной модели накрутить простое и непротиворечивое API. Что-то будет обязательно потеряно. Не стоит думать, что команда .NET с бухты-барахты написала этот код. Я уверен, что каждый метод, каждая деталь реализации была продумана тщательнейшим образом, с многочисленными спорами и обсуждениями в кулуарах.
А чтобы писать нормальный код, достаточно взять за правило хранить и передавать дату только в UTC (и все манипуляции арифметические тоже), а в локальное время переводить только при необходимости вывести её пользователю.
А чтобы писать нормальный код, достаточно взять за правило хранить и передавать дату только в UTC (и все манипуляции арифметические тоже), а в локальное время переводить только при необходимости вывести её пользователю.
+2
Все так. но
Парсинг даты из строки идет только в local!!!
Таймзоны в windows кривые! соответственно преобразования работают неправильно. Разве-что сервер настраивать на UTC в качестве локальной зоны, тогда еще както будет работать
Единого объекта для поясного времени с поддержкой арифметики и преобразований нет
:(
Парсинг даты из строки идет только в local!!!
Таймзоны в windows кривые! соответственно преобразования работают неправильно. Разве-что сервер настраивать на UTC в качестве локальной зоны, тогда еще както будет работать
Единого объекта для поясного времени с поддержкой арифметики и преобразований нет
:(
0
А она столь же проста как и дотнетовое API? Я толком не смотрел, но на первый взгляд классов там намного больше по сравнению с 2 классами DateTime, DateTimeOffset и одним енумом DateTimeKind. Утверждалось что при создании упрощенной модели появляются проблемы, а не то, что для этой задачи невозможно построить внятную объектно-ориентированную модель вовсе.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что же всё-таки не так со структурой DateTime?