Why you should use DateTimeOffset instead of DateTime in .NET
Post by
Damian Sibiński
Published
2 February 2025
IIn .NET applications we often use DateTime to store dates and times. The problem is that DateTime does not store time zone information — it only has a Kind flag (Unspecified, Utc, Local), which leads to ambiguity and bugs when users are in different time zones or when persisting to the database and API.
DateTimeOffset stores a point in time along with the offset from UTC (e.g. +01:00). This way you know exactly when in UTC the event occurred, and displaying it in the user's local time zone is a matter of conversion at presentation time. Comparisons between values are correct regardless of the server's time zone, and serialization to JSON (ISO 8601) or the database is unambiguous.
Use DateTimeOffset for all points in time that have business meaning — user registration, order, event log. Reserve DateTime only for 'calendar' dates without a specific time (e.g. date of birth).
When to use which type?
DateTimeOffset: events, audit, logs, anything that has a 'point in time' and may be consumed across time zones. DateTime: only dates without time, or when you work in a single, fixed time zone and do not export data externally. In Entity Framework Core both types map to the appropriate columns; for DateTimeOffset SQL Server uses datetimeoffset, which stores the offset and eliminates guesswork on read.
Loading comments…