DateTime vs DateTimeOffset в C#: какой тип выбрать для работы с датами и временными зонами?

Основное различие: что хранят DateTime и DateTimeOffset

Главное отличие — в информации, которую несет каждый тип:

• DateTime хранит только дату и время. Свойство .Kind (Unspecified, Utc, Local) — это лишь флаг, который не хранит реальное смещение. Он говорит: "я думаю, что это время UTC" или "я думаю, что это местное время". Но никакой привязки к часовому поясу нет.
• DateTimeOffset хранит дату, время и смещение от UTC (например, +03:00 для Москвы летом). Это самодостаточная структура: зная значение и смещение, вы всегда можете точно вычислить момент в UTC.

Когда использовать DateTime

DateTime идеален, когда:

• Вы работаете только с датой (без времени) — например, день рождения, дата выпуска продукта. Тогда используйте DateTime.Date или DateOnly (.NET 6+).
• Время не привязано к конкретному часовому поясу (например, "открытие магазина в 9:00" — это локальное время для каждого магазина).
• Вы работаете с системным временем (например, DateTime.Now для логов на одном компьютере, где часовой пояс не меняется).

Когда использовать DateTimeOffset

DateTimeOffset — выбор по умолчанию для большинства современных приложений, потому что:

• Вы храните момент во времени, который должен быть однозначно интерпретирован (время события, дедлайн, timestamp из API).
• Приложение работает с пользователями из разных часовых поясов.
• Данные передаются между системами (например, через REST API, базы данных).
• Вы хотите избежать ошибок при переводе часов (летнее/зимнее время).

Примеры кода

Проблема с DateTime:

// Пользователь в Москве (UTC+3) создает задачу
DateTime userLocal = new DateTime(2025, 6, 15, 14, 0, 0, DateTimeKind.Local);
// Сервер в UTC (Лондон) сохраняет это как...
DateTime stored = userLocal.ToUniversalTime(); 
// Результат: 2025-06-15 11:00:00 UTC

// Другой пользователь во Владивостоке (UTC+10) читает задачу
DateTime displayed = stored.ToLocalTime(); 
// Ошибка! Отобразится как 2025-06-15 21:00:00 (UTC+10), хотя москвич имел в виду 14:00 МСК

Решение с DateTimeOffset:

// Пользователь в Москве создает задачу
DateTimeOffset userMoment = new DateTimeOffset(2025, 6, 15, 14, 0, 0, TimeSpan.FromHours(3));
// Сохраняем как есть — и UTC, и смещение
// При передаче в БД или API — сериализуется в ISO 8601: "2025-06-15T14:00:00+03:00"

// Другой пользователь во Владивостоке читает
DateTimeOffset vlMoment = userMoment.ToOffset(TimeSpan.FromHours(10));
// Результат: 2025-06-15 21:00:00 +10:00 — абсолютно корректно!

Практические советы

• Для хранения в БД: используйте DateTimeOffset (в SQL Server — тип datetimeoffset). Это сохранит информацию о часовом поясе.
• Для API: всегда передавайте DateTimeOffset в формате ISO 8601 (например, "2025-06-15T14:00:00+03:00").
• Для отображения пользователю: конвертируйте DateTimeOffset в местное время пользователя с помощью .ToOffset() или .LocalDateTime.
• Текущее время: используйте DateTimeOffset.UtcNow вместо DateTime.UtcNow — это дает гарантию, что смещение всегда +00:00.

Итог

DateTimeOffset — это современный и безопасный выбор для 90% случаев. DateTime оставьте для:

• Чистых дат (без времени).
• Локального времени, которое не нужно передавать (например, таймер в десктопном приложении).
• Работы с устаревшими API, которые требуют DateTime.

Если сомневаетесь — выбирайте DateTimeOffset. Это спасет вас от множества багов, связанных с часовыми поясами.

// DateTimeOffset сериализуется корректно
var dt = new DateTimeOffset(2025, 6, 15, 14, 0, 0, TimeSpan.FromHours(3));
string json = JsonSerializer.Serialize(dt);
// Результат: "2025-06-15T14:00:00+03:00"

// DateTime может потерять информацию о часовом поясе
DateTime dt2 = new DateTime(2025, 6, 15, 14, 0, 0, DateTimeKind.Local);
string json2 = JsonSerializer.Serialize(dt2);
// Результат: "2025-06-15T14:00:00" (без смещения!)