Ответ - это зависит.
DateTimeOffset - это отметка времени + смещение UTC.Проблема состоит в том, что несколько часовых поясов могут совместно использовать одно и то же смещение, но они могут не использовать одни и те же правила перехода на летнее время (помимо прочего), и поскольку DateTimeOffset не имеет никакого понятия о TimeZone, это приводит к неоднозначности.Однако это может быть хорошо, если вы храните временные метки на стороне сервера, которые не отображаются пользователю, и пользователь не взаимодействует с ними.Примером этого может быть регистрация на стороне сервера, я думаю.
ИМХО самый безопасный подход при работе с пользовательским вводом, отображением пользователя, запросом пользователя и т. Д., И т. Д., Это хранить DateTime s и сохранять полный часовой поясИнформация.Вы можете использовать TimeZoneInfo.Serialize(...), который выводит полную информацию о часовом поясе в строку и сохраняет ее в базе данных, которую впоследствии можно десериализовать в экземпляр TimeZoneInfo через TimeZoneInfo.Deserialize(...) и использовать для преобразования DateTime в местное / utc datetime.Это безопасно, потому что нет никакой двусмысленности, а также даже если часовой пояс изменяется (и они меняются - например, изменения летнего времени), ваши данные все еще непротиворечивы.Конечно, вам нужно будет позаботиться об обновлении базы данных, чтобы поддерживать ее синхронизацию (довольно редко).
При вышеупомянутом подходе вы можете сохранить DateTimes в UTC или Local, и вам нужно решить, какая из них зависитна случай использования.При хранении дат и времени в UTC одна забавная вещь заключается в том, что понятие «сегодня» пользователя становится немного более сложным - об этом можно прочитать в моем блоге здесь .