Комментарии 5
Отличная новая возможность! Спасибо за столь информативную и хорошо написанную статью
Например, если восьмичасовая смена сотрудника начинается в 18:00, TimeOnly позволит правильно прибавить эти восемь часов к времени начала смены и получить 02:00;
А если смена приходится на день перехода на летнее/зимнее время?
Тогда (как я понимаю) этот тип данных не для вас и вам нужна библиотека Noda Time.
p.s. Тип TimeOnly содержит только время и не имеет привязки ни к какой дате, поэтому он и не может даже в теории реагировать на смену часовых поясов.
p.s. Тип TimeOnly содержит только время и не имеет привязки ни к какой дате, поэтому он и не может даже в теории реагировать на смену часовых поясов.
Так моя претензия была к вот этому:
Нет, не позволит он сделать это правильно. Результат вы получите, но правильность его, будет зависеть отфазы Луны того, в какой стране вы находитесь, и какой сегодня день. Очевидно, что для этой задачи нужно использовать тип, содержащий дату и время. Немного менее очевидно, что операцию следует производить в UTC, а затем, результат преобразовать в нужную тайм зону, с помощью TimeZoneInfo. Потому что ни DateTime, ни даже рекомендованный для большинства задач DateTimeOffset (вот это ещё менее очевидно) не учитывают переход на зимнее/летнее время, в арифметических операциях с датами и временем, т.к. оба не содержат сведения о тайм зоне. DateTimeOffset содержит только смещение относительно UTC, а не конкретную тайм зону. А правила перевода стрелок, в разных тайм зонах могут отличаться, даже если текущее смещение относительно UTC у них совпадает. И только TimeZoneInfo умеет корректно переводить стрелки, в то время, как все остальные типы, могут только «переводить стрелки» на него.
Во первых, не «тогда», а «всегда», если вам нужна стабильная работа программы, в любой день, в любом регионе. Во вторых, причём тут я? Задача, о вычислении рабочей смены — не моя, я только комментарий разместил. Правильней будет сказать, что этот тип данных, в общем случае, не подходит для озвученной задачи: «вычисление времени окончания рабочей смены, зная время её начала».
Что касается самого типа TimeOnly, его я здесь не критикую. В этой ситуации он ведёт себя так же, как и другие типы даты/времени из стандартной библиотеки. И если такое поведение и ругать, то ругать надо всю библиотеку, а не этот новый тип. Но вот приведённый здесь пример использования, однозначно, плохой.
Всё верно. Пожалуй, даже очевидно. Я бы понял, если бы в статье этому нюансу просто не уделили внимание — можно было бы списать на эту самую очевидность. Но может всё не так уж и очевидно, раз в статье привели, очевидно, ошибочный пример использования? Проблема в том, что по таким статьям учатся новички. Вот загуглит кто-то через пол-года, что это за новый тип данных, прочитает эту статью, увидит неправильные примеры, и начнёт делать так, как делать не надо. А ведь ошибки в работе с датой и временем — одни из самых противных, потому как вылезают только в определённые моменты времени, оставаясь скрытыми во время тестирования — настоящие часовые бомбы в вашем коде.
Да и в целом, тема даты и времени — одна из тех, что оказываются значительно глубже и сложнее, чем кажется на первый взгляд. Как раз, обсуждаемый здесь, неудачный пример, закравшийся в неплохую, в целом, статью — лишнее тому подтверждение. Да и упомянутая «Noda Time», тоже не даром появилась, а как следствие недостатков стандартной библиотеки, хотя последнюю тоже не дураки делали.
З.Ы. я тут целую портянку раскатал. Предыдущий мой комментарий получился неоднозначным именно потому, что в тот момент у меня не было времени написать развёрнуто — представил в голове вот такую портянку, и решил ограничиться наводящим вопросом, в надежде, что кто-то распишет всё за меня. Но пришлось, всё же развернуть мысль. Будьте внимательны при работе с датами и временем, здесь много возможностей выстрелить себе в ногу.
TimeOnly позволит правильно прибавить эти восемь часов к времени начала смены и получить 02:00
Нет, не позволит он сделать это правильно. Результат вы получите, но правильность его, будет зависеть от
Тогда (как я понимаю) этот тип данных не для вас
Во первых, не «тогда», а «всегда», если вам нужна стабильная работа программы, в любой день, в любом регионе. Во вторых, причём тут я? Задача, о вычислении рабочей смены — не моя, я только комментарий разместил. Правильней будет сказать, что этот тип данных, в общем случае, не подходит для озвученной задачи: «вычисление времени окончания рабочей смены, зная время её начала».
Что касается самого типа TimeOnly, его я здесь не критикую. В этой ситуации он ведёт себя так же, как и другие типы даты/времени из стандартной библиотеки. И если такое поведение и ругать, то ругать надо всю библиотеку, а не этот новый тип. Но вот приведённый здесь пример использования, однозначно, плохой.
он и не может даже в теории реагировать на смену часовых поясов
Всё верно. Пожалуй, даже очевидно. Я бы понял, если бы в статье этому нюансу просто не уделили внимание — можно было бы списать на эту самую очевидность. Но может всё не так уж и очевидно, раз в статье привели, очевидно, ошибочный пример использования? Проблема в том, что по таким статьям учатся новички. Вот загуглит кто-то через пол-года, что это за новый тип данных, прочитает эту статью, увидит неправильные примеры, и начнёт делать так, как делать не надо. А ведь ошибки в работе с датой и временем — одни из самых противных, потому как вылезают только в определённые моменты времени, оставаясь скрытыми во время тестирования — настоящие часовые бомбы в вашем коде.
Да и в целом, тема даты и времени — одна из тех, что оказываются значительно глубже и сложнее, чем кажется на первый взгляд. Как раз, обсуждаемый здесь, неудачный пример, закравшийся в неплохую, в целом, статью — лишнее тому подтверждение. Да и упомянутая «Noda Time», тоже не даром появилась, а как следствие недостатков стандартной библиотеки, хотя последнюю тоже не дураки делали.
З.Ы. я тут целую портянку раскатал. Предыдущий мой комментарий получился неоднозначным именно потому, что в тот момент у меня не было времени написать развёрнуто — представил в голове вот такую портянку, и решил ограничиться наводящим вопросом
Интересно, для Марса уже есть структурка :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Даты, время и часовые пояса: улучшения в .NET 6