Programming
DateTime Object
ISO 8601
String Format
Coding Tutorials

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.

csharp
1using System;
2
3DateTime value = DateTime.UtcNow;
4string iso = value.ToString("O");
5
6Console.WriteLine(iso);

"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.

csharp
1using System;
2
3DateTime utcValue = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Utc);
4DateTime localValue = DateTime.Now;
5DateTime unspecified = DateTime.SpecifyKind(DateTime.Now, DateTimeKind.Unspecified);
6
7Console.WriteLine(utcValue.ToString("O"));
8Console.WriteLine(localValue.ToString("O"));
9Console.WriteLine(unspecified.ToString("O"));

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.

csharp
1using System;
2
3DateTime localTime = DateTime.Now;
4string isoUtc = localTime.ToUniversalTime().ToString("O");
5
6Console.WriteLine(isoUtc);

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.

csharp
1using System;
2
3DateTimeOffset dto = DateTimeOffset.Now;
4string iso = dto.ToString("O");
5
6Console.WriteLine(iso);

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.

csharp
1using System;
2
3DateTime today = DateTime.Today;
4string isoDateOnly = today.ToString("yyyy-MM-dd");
5
6Console.WriteLine(isoDateOnly);

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.

csharp
1using System;
2using System.Globalization;
3
4string text = "2026-03-11T15:42:18.1234567Z";
5DateTime parsed = DateTime.Parse(text, null, DateTimeStyles.RoundtripKind);
6
7Console.WriteLine(parsed.Kind);
8Console.WriteLine(parsed.ToString("O"));

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.
  • 'DateTimeKind affects whether the result has Z, an offset, or ambiguous semantics.'
  • Use DateTimeOffset when 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.

Course illustration
Course illustration

All Rights Reserved.