Given a DateTime object, how do I get an ISO 8601 date in string format?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
In .NET, DateTime can be formatted as ISO 8601 directly with standard format strings. The tricky part is not the string call itself; it is choosing whether you want local time, UTC, or an offset-preserving representation.
The Short Answer in C#
If you want a full ISO 8601 timestamp that round-trips cleanly, use the round-trip format specifier.
"O" and "o" are equivalent in .NET. They produce a round-trip ISO 8601 style string such as 2026-03-11T15:42:18.1234567Z.
This is usually the best default because it preserves enough information to parse the timestamp back into the same instant.
DateTimeKind Changes the Output
A DateTime value in .NET carries a Kind, which can be Utc, Local, or Unspecified. That affects the ISO 8601 string you get.
Typical results look like this:
- UTC value ends with
Z - local value ends with an offset such as
-05:00 - unspecified values have no trustworthy time-zone meaning even if a formatted string is produced
That means formatting alone does not fix ambiguous time-zone data. If the timestamp's meaning matters across systems, normalize it first.
Prefer UTC for APIs and Storage
When writing timestamps to APIs, logs, message queues, or databases, UTC is usually the safest choice.
This avoids ambiguity and makes comparison easier across servers in different time zones.
If another system expects a trailing Z, converting to UTC before formatting is the right step. Merely replacing an offset string with Z would be incorrect.
Use DateTimeOffset When You Care About the Offset
DateTime is often enough, but DateTimeOffset is a better choice when you want to preserve the original offset explicitly.
For distributed systems, DateTimeOffset is often easier to reason about because it represents an instant plus its offset more explicitly than DateTime with an implied Kind.
Date-Only Versus Full Timestamp
Sometimes the question is not about a full timestamp but just the calendar date. If you want ISO 8601 date-only output, use a custom format string.
That is still ISO 8601 compliant for the date-only representation. It is different from the full round-trip timestamp and should not be confused with it.
Parsing Back Safely
The round-trip format is useful because it is easy to parse back.
If your application serializes and deserializes timestamps across services, using "O" in both directions is a solid default.
Common Pitfalls
The biggest mistake is formatting a local DateTime and assuming the result is UTC. It is not unless you converted it.
Another mistake is using DateTimeKind.Unspecified values and expecting ISO output to carry reliable time-zone semantics. The string may look valid, but the meaning is ambiguous.
A third issue is using a custom format that drops precision or offset information when the timestamp needs to be parsed back later.
Finally, do not use culture-specific formatting methods for machine-readable timestamps. ISO 8601 output should be culture-invariant.
Summary
- In .NET, the usual ISO 8601 answer is
dateTime.ToString("O"). - Use UTC when you need stable cross-system timestamps.
- '
DateTimeKindaffects whether the result hasZ, an offset, or ambiguous semantics.' - Use
DateTimeOffsetwhen preserving the original offset matters. - For date-only output, use
yyyy-MM-dd. - Choose formatting based on whether you need a display string or a round-trip machine-readable timestamp.

