Действительно ли TimeSpan является ненужным?

Дата не ведет себя как целое число, я не могу вспомнить классификацию алгебры, но учтите это:

Date + Span = Date
Date - Date = Span  
Date + Date = undefined

Span + Span = Span
Span - Span = Span

Для любого данного года,

10 feb + 10 days = 20 feb
20 feb - 20 jan  = 31 days
20 jan + 20 feb  = ???

Это последнее вычисление можно интерпретировать как имеет смысл, когда мы рассматриваем Date как Days-Since-StartDate. Но значение будет таким же произвольным, как и выбор StartDate.

(Говоря как математик) Это потому, что арифметические операции над «датой» не являются закрытыми или четко определенными, что требует дополнительной структуры.

Например, 1 января, 2000 - 1 декабря 1999 = ...? Мы знаем, что между ними 31 день, но если бы это было истолковано как дата, то ответ был бы Эпоха (т.е. ноль) + 31 день. Это больше не действительная «дата».

Точно так же не все арифметические операции с целыми числами четко определены (1/2 не имеет ответа в целых числах ... целочисленная математика здесь возвращает ноль, но 0 * 2 = 0, а не 1, как вы ожидали). Это вызывает необходимость в дополнительной структуре, которую мы называем дробями.

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

Различие между интервалом времени и датой сводится к сложению. Есть смысл добавить два временных интервала, но нет смысла добавлять две даты , если у вас нет произвольной контрольной даты . Не позволяя добавлять даты, вы абстрагируетесь от произвольной контрольной даты. Я не знаю, какая дата «0» в .Net, и мне никогда не нужно было знать. Разве это не мило?

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

Одна из причин заключается в том, что разделение на типы предотвращает класс ошибок, в которых, как вы думаете, у вас есть относительное время, но на самом деле есть абсолютное время, и наоборот. Например, добавление двух абсолютных значений времени может быть отмечено как ошибка компилятора, если эти два типа являются отдельными.

Кроме того, IntelliSense (и обнаружение для новичков) работает лучше, когда количество членов меньше - за счет разделения методов между двумя типами работа с каждым из них становится проще.

На вопрос наоборот: какая польза от ослабления системы типов в этом отношении?

Все дело в соотношении затрат и выгод и DateTime имеет большое преимущество в уменьшении количества ошибок из-за нелогичных вычислений даты / времени, запрещая такие действия. DateTime существует во многом по тем же причинам, что и система строгой проверки типов в первую очередь: чтобы сделать семантические ошибки в коде, создавайте сообщения времени компиляции. которые уведомляют программистов об ошибках в их коде.

И наоборот, есть цена за наличие DateTime : zilch.

Теперь рассмотрите возможность удаления DateTime . Что мы получим?

Чтобы ответить прямо на ваш вопрос: «Разве TimeSpan не является избыточным?» Абсолютно нет, это уменьшает количество ошибок. Для меня определенно имеет.

Подумайте об этом концептуально. Если я скажу вам, что у меня вечеринка через 7 дней, это будет «7 дней» в этом предложении как свидание. Могу я просто сказать, что у меня вечеринка 7 дней? Конечно, нет, потому что 7 дней - это не свидание. Одна из ключевых идей объектно-ориентированного программирования - представить подобные концепции в системе как типы. Верно, что мы могли бы представить все в виде целого числа (и на самом деле многие люди имеют и делают), но в объектно-ориентированном программировании у нас есть понятие типов элементов, их поведения и свойств, и в этом смысле это делает смысл иметь объект, который выражает это.

Я думаю, вы могли бы привести противоположный аргумент, что DateTime является избыточным, и у нас должно быть только TimeSpan :)

Серьезно, все даты на самом деле это просто промежутки времени. Все они относятся к некоторой отправной точке. Технически, в христианском календаре нет «нулевого года» (поскольку на самом деле нельзя иметь «нулевой год нашего господина»), но если мы назначим 12:00 1 января 0001 г. до н.э. в качестве «нулевой точки» , то каждую дату, которая наступает после (или раньше), можно рассматривать как относительную к этой дате. Итак, 12:00 AM 19 сентября 2009 г. будет иметь TimeSpan 734033 дня.

Итак, математически , DateTime и TimeSpan являются избыточными. Но когда мы пишем код, мы пытаемся передать гораздо больше, чем просто абстрактные математические конструкции. Любой данный экземпляр DateTime на самом деле может быть просто промежутком времени относительно некоторой произвольной нулевой точки, но для большинства людей, читающих ваш код, это будет означать конкретную точку в календаре. Аналогично TimeSpan подразумевает разрыв между двумя точками в календаре.

В этом случае Microsoft предпочла быть ясной, а не скупой. Не могу сказать, что не согласен с этим решением.

сахар не более или менее ....