When would you use DateTime, DateTimeOffset, and TimeZoneInfo, and how would you model time across an API and database?

DateTime, DateTimeOffset, and time-zone boundaries in .NET

Distinguishes instants, local calendar values, offsets, and named time zones so APIs and persistence survive daylight-saving and locale boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

For an event that happened at a precise instant, I prefer DateTimeOffset at boundaries because the value includes an offset and maps unambiguously to UTC. A UTC DateTime can also represent an instant when its Kind is handled consistently, but an unspecified or local value is easy to misinterpret. TimeZoneInfo applies named time-zone rules when converting for users. A date-only business value such as a birthday uses DateOnly, while a local opening time may use TimeOnly plus the location's zone and business rules.

Full answer below

Practice focus

DateTime, DateTimeOffset, UTC, offsets, TimeZoneInfo, daylight-saving transitions, local calendar values, serialization, persistence, and testing.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Time bugs usually come from mixing an instant on the global timeline with a local business date or future wall-clock schedule. The type and stored data must preserve the meaning the product actually needs.
For an event that happened at a precise instant, I prefer DateTimeOffset at boundaries because the value includes an offset and maps unambiguously to UTC. A UTC DateTime can also represent an instant when its Kind is handled consistently, but an unspecified or local value is easy to misinterpret. TimeZoneInfo applies named time-zone rules when converting for users. A date-only business value such as a birthday uses DateOnly, while a local opening time may use TimeOnly plus the location's zone and business rules.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I store instants in a normalized form and preserve the original offset only when it has product or audit meaning. An offset is not a time zone: several zones share one offset, and daylight-saving rules change over time. For a future appointment defined as 09:00 Europe/Skopje, I store the local date and time plus the zone identifier, then derive the instant according to explicit handling for invalid or ambiguous transitions. API contracts use ISO 8601 with an offset or Z, and validation rejects timestamps whose intended semantics are unclear.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I name each field by meaning: occurred-at instant, local business date, duration, or recurring schedule. Database types and ORM conversions are reviewed so offsets, precision, and Kind are not silently lost. I avoid adding 24 hours when the requirement is the same local time tomorrow, and I do not use the server's local zone as an implicit default. Cross-platform zone identifiers, rule updates, and historical changes need a deliberate policy. Sorting and expiry calculations use instants; grouping by a user's day converts through their zone at the query boundary or a tested read model. Tests freeze the clock and cover UTC boundaries, non-hour offsets, leap days, ambiguous fall-back times, invalid spring-forward times, serialization round trips, and clients in another zone. Operational logs use UTC instants while user-facing messages retain the requested locale and zone context.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Treating a numeric offset as a permanent time-zone identity.
Storing server-local DateTime values with unspecified meaning.
Using one timestamp type for birthdays, durations, and instants.
Adding fixed hours to implement calendar scheduling.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Production behavior depends on the machine's local time zone.
The API accepts timestamps without an offset but assumes UTC silently.
A future recurring schedule stores only its first UTC instant.
Daylight-saving transitions are absent from tests.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

Why is DateTimeOffset not a complete time zone?
How would you store a future local appointment?
When is DateOnly a better model?

Continue the section

Next in C# and .NET: Value and reference semantics

Step 2 of 12

Value types, reference types, and parameter passing in C#

Opening drill

When would you use DateTime, DateTimeOffset, and TimeZoneInfo, and how would you model time across an API and database?

DateTime, DateTimeOffset, and time-zone boundaries in .NET

Distinguishes instants, local calendar values, offsets, and named time zones so APIs and persistence survive daylight-saving and locale boundaries.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

When would you use DateTime, DateTimeOffset, and TimeZoneInfo, and how would you model time across an API and database?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

When would you use DateTime, DateTimeOffset, and TimeZoneInfo, and how would you model time across an API and database?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section