Что же всё-таки не так со структурой DateTime?

[kekekeks]

DateTime utc = DateTime.UtcNow;

DateTime local = DateTime.Now;

bool mystery = local == utc;

Код изначально кривой и писал его человек, не понимающий того, как он работает. Даже выражение DateTime.Now == DateTime.Now будет истинным или ложным в зависимости от точности таймера, отсутствия или наличия переключения контекста потока и погоды на Марсе.

[kekekeks]

Собсно, прогнал для теста:

$ 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

[Weageoo]

Оо, судя по коду теста…

[romik]

Например, предположим, что часы не тикнули между вызовами двух свойств в ниже приведенном коде.

[ertaquo]

Может не DateTime.Now == DateTime.Now, а DateTime.UtcNow == DateTime.Now?

[Nerten]

Нет, человек все правильно сказал

[romik]

А я-то думал, что придумать что-то хуже стандартных джавовских Date и Calendar нельзя… Оказывается, можно :-)

[grossws]

В Java это проблема частично решается Joda Time.
В jdk7 так и не вошло улучшение JSR-310 от Стефена Коулборна (автора joda time).
Остается надеяться, что оно войдет в java se 8.

[Bick]

Если честно…
а) Мозг частично сломан.
б) Чёрт меня дёрнул полезть смотреть про секунду координации. В итоге, как всегда, оказался довольно далеко от точки входа в вики.
в) Узнал для себя довольно много интересного и, вероятно, полезного. Осталось проанализировать.

За перевод спасибо — и статья отлична, и перевод.

[ertaquo]

Где тут неоднозначность?
Читаем 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.

[alexeyrom]

Именно что «читаем MSDN». Неоднозначности нет, а вот неочевидность — есть.

> Меня мало волнует, какой ответ верен — неочевидность логики поведения кода является признаком более глубоких проблем.

[onk]

наконецто ктото занялся вопросом о дате и времени в Windows приложениях
для десктоп приложений чаще всего не принципиально — используется Kind=local и всех делов
но если возникла потребность представления информации в разных часовых поясах (в вебе это наиболее часто), то все не просто плохо, а очень плохо
зону нужно учитывать отдельно, операции с датами сделаны через ж

дату как дату из DateTime получили, но сравнивать как дату с другим DateTime уже не корректно — надо опять доставать проперть Date

но это еще все цветочки
с августа месяца у Windows (не .Net) категорическая проблема с записями часовых поясов
после августовского патча часовые пояса для России закончились 31 декабря 2010 года. попытка преобразования дат раньше 1.01.2011 приводит к ошибкам — летом легко получить +5 для москвы при пересчете через UTC
сейчас этот патч просто откатили!
посмотрите в настройках часового пояса в винде для России (Москва например) — там снова есть возможность перехода на летнее время!

[kekekeks]

В вебе операции всегда производятся с временем по UTC, а в локальное время оно превращается перед передачей пользователю.

[elw00d]

Да нормальное API. Проблем, конечно, с датами и временем куча, но эта сложность обусловлена объективной сложностью модели. Нельзя поверх сложной модели накрутить простое и непротиворечивое API. Что-то будет обязательно потеряно. Не стоит думать, что команда .NET с бухты-барахты написала этот код. Я уверен, что каждый метод, каждая деталь реализации была продумана тщательнейшим образом, с многочисленными спорами и обсуждениями в кулуарах.

А чтобы писать нормальный код, достаточно взять за правило хранить и передавать дату только в UTC (и все манипуляции арифметические тоже), а в локальное время переводить только при необходимости вывести её пользователю.

[onk]

Все так. но
Парсинг даты из строки идет только в local!!!
Таймзоны в windows кривые! соответственно преобразования работают неправильно. Разве-что сервер настраивать на UTC в качестве локальной зоны, тогда еще както будет работать
Единого объекта для поясного времени с поддержкой арифметики и преобразований нет
:(

[alexeyrom]

> Проблем, конечно, с датами и временем куча, но эта сложность обусловлена объективной сложностью модели. Нельзя поверх сложной модели накрутить простое и непротиворечивое API. Что-то будет обязательно потеряно.

Ну так и скажите, что именно потеряно в Noda Time? И заодно — в Joda Time?

[elw00d]

А она столь же проста как и дотнетовое API? Я толком не смотрел, но на первый взгляд классов там намного больше по сравнению с 2 классами DateTime, DateTimeOffset и одним енумом DateTimeKind. Утверждалось что при создании упрощенной модели появляются проблемы, а не то, что для этой задачи невозможно построить внятную объектно-ориентированную модель вовсе.