Всем привет! Хотел бы узнать, кто-нибудь использовал NodaTime в продакшене?

Насколько сложно было переходить из DateTime к типам из этой бибилотеки? И почему решили переходить на эту библиотеку?

Айрат использовал. Почему решили переходить — ну так а других нету (для ряда кейсов, когда тебе нужно что-то делать со временем).

А можно Айрата отметить? Хотел бы поинтересоваться насчёт процесса этого)

@omgszer, принимай пополнение!

спасибо!

Если тебе надо делать что-то больше со временем, например логистика между таймзонами - то очень надо.

Хотел бы по подробнее узнать насчёт проекта, в котором использовал, и использовали ли эту библиотеку изначально или потом перешли? Используете ли EF\Dapper или какие-то иные взаимодействия с бд, как решали эти вопросы?

там сразу было понятно, что стандартный инструментарий не вывезет, т.к. в нём не было банальных примитивов для работы с локальным временем и временем в таймзоне. У нас был большой модуль, который считал время доставки (и для клиента при заказе, и гораздо более точное для репортов по логистике и оценке костов). И алгоритм должен был учитывать - время окончания смены в одной таймзоне - праздники - время в полёте в целом было непросто!

а почему не перевели всё в UTC? а уж затем переводи куда захочется, в любую таймзону

а ты, я вижу, эксперт!

там же всё не так просто) взять те же смены зимнего\летнего времени, по-моему где-то они остались

все international-проекты делали как UTC - оно как раз при выводе в локальную DateTime как раз учитывает все смены дат и т.п.

как мне время в UTC поможет узнать что доставка клиенту будет в 02:00 ночи по ЕГО времени?

неплохо, а там выходной

это уже другая задача - формируем окна доступности сервиса (опять же, храним в UTC)

а если взять проблему сравнивания дат? то как именно будет происходить сравнивание? или просто договориться и сделать что в приложении в бэкенде у на всё в utc и мы работаем только с ним? а что для работы с отдельно датой\отдельно временем? а что если нам например нужно сравнить с днём текущим? ну и ещё как я помню там был спектр вопросов который помогает решать NodaTime upd: насчёт сравнения, мы можем сравнить 2 даты с одинаковыми тиками, но разными типами, и они будут равны, т.е. для Мск например сейчас 21:51 28.09.23 и если мы берем utc то это будет 18:51 28.09.23, и эти даты в своей сути представляют один момент времени, но в рамках DateTime важны только тики, но не типы и в этом по-моему основная претензия к DateTime. DateTime содержит 3 типа (Unspecified, Local, Utc) в рамках одной структуры, хотя каждая из них по своей логике должна работать как отдельный понятный механизм, с ожидаемым и логичным поведением upd1: а если поверх этого накатить работу с бд, реализацией сохранения\изменения\конвертации дат, то есть большой пласт вопросов, которые тоже решаются, как по мне не однозначно (хотя возможно, если изначально придерживаться позиции UTC для DateTime в рамках приложения, и написать десяток тестов, показывающих как работать с теми или иными датами\временем\датой+время, то это будет просто, но всё же NodaTime интересная библиотека, которую хотелось бы попробовать)

всё уносим в UTC