.NET 6: Новые Структуры Даты и Времени
Давняя проблема библиотеки базовых классов .NET заключается в невозможности раздельного представления значений даты и времени. Новые структуры .NET 6
DateOnly и TimeOnly призваны исправить это упущение.Как следует из названия, они предназначены для хранения только даты и только времени соответственно. Таким образом, они отвечают принципу SRP в том смысле, что не могут играть разные роли (раньше
DateTime использовалась для хранения и только даты, и только времени, и даже интервалов).Исходное имя структуры
DateTime было просто Date. Это всё ещё справедливо для VB, где ключевое слово Date продолжает ссылаться на DateTime. Таким образом, название DateOnly было выбрано, чтобы избежать путаницы. Другая причина заключается в том, что DateTime.Date возвращает значение DateTime. Это уже нельзя изменить, но новички часто ожидают, что это свойство возвращает только дату. Поэтому новое свойство, возвращающее DateOnly, можно назвать DateTime.DateOnly.Точно так же имя
TimeOfDay проблематично, поскольку многие свойства и методы используют его для ссылки на значение DateTime или TimeSpan.Сериализация
DateOnly и TimeOnly не будут реализовывать атрибут Serializable. В .NET Core и более поздних версиях этот атрибут считается устаревшим, как и библиотеки сериализации, которые на него полагаются.Был запрос на атрибут
IXmlSerializable и его эквивалент в для JSON. Однако DateOnly и TimeOnly должны быть помещены в одну из библиотек нижнего уровня NET, где такие атрибуты недоступны. Таким образом, сериализаторам необходимо будет включить собственную обработку этих новых типов. Такое же изменение придётся сделать и в драйверах баз данных.Это может привести к тому, что после выпуска .NET 6 в течение какого-то времени нельзя будет использовать
DateOnly и TimeOnly в некоторых сценариях, пока сериализаторы не подстроятся.DateTimeOnlyПытаясь решить проблему часового пояса, .NET 2 представила свойство
DateTime.Kind. Разработчики имели возможность аннотировать свои значения даты и времени с помощью флага, указывающего, представляет ли значение местный часовой пояс, всемирное координированное время или неуказанный часовой пояс. На самом деле это привело к тому, что разработчики были вынуждены указывать эту информацию или сталкиваться с неожиданными ошибками.Что еще хуже, свойство
Kind использовалось непоследовательно. Например, многие сериализаторы, видя его, добавляли смещение при экспорте значения. Это приводило к трудно диагностируемым ошибкам, поскольку только некоторые даты (например, полученные из DateTime.Now) сериализовывались со смещением. А операторы сравнения полностью игнорировали Kind. Предполагалось, что разработчик сам проверит свойство Kind и при необходимости выполнит преобразование часового пояса.Чтобы устранить эти проблемы, есть запрос на новую структуру
DateTimeOnly, которая в основном работает так же, как DateTime в .NET 1 (т.е. дата и время без указания часового пояса).Источник: https://www.infoq.com/news/2021/04/Net6-Date-Time/