DateTime.ToString()

wassupy.com

shorthand format strings

dates

d 4/26/2025
D Saturday, April 26, 2025
m April 26
M April 26
y April 2025
Y April 2025

times

t 1:32 AM
T 1:32:17 AM

combos

f Saturday, April 26, 2025 1:32 AM
F Saturday, April 26, 2025 1:32:17 AM
g 4/26/2025 1:32 AM
G 4/26/2025 1:32:17 AM
o 2025-04-26T01:32:17.2170197
r Sat, 26 Apr 2025 01:32:17 GMT
s 2025-04-26T01:32:17
u 2025-04-26 01:32:17Z
U Saturday, April 26, 2025 1:32:17 AM

custom date bits

era

%g AD
gg AD

year

yyyyy 02025
yyyy 2025
yyyy 2025
yy 25
y April 2025

month

MMMM April
MMM Apr
MM 04
%M 4

day

dddd Saturday
ddd Sat
dd 26
%d 26

custom time bits

hour

HH 01
%H 1
hh 01
%h 1

minute

mm 32
%m 32

second

ss 17
%s 17

subsecond

%f 2
ff 21
fff 217
ffff 2179
fffff 21793
ffffff 217931
fffffff 2179318

miscellaneous bits

date separator

%/ /

time separator

%: :

AM/PM

%t A
tt AM

time zone1

%K
%z +0
zz +00
zzz +00:00

Pitfalls and traps

General advice

Dates, times, and time zones are tricky. In .NET, there are subtle differences that can be challenging to spot. My general advice is:

Other gotchas

TimeZoneInfo.ConvertTime(...) returns a DateTime with Kind = Unspecified. For example:

DateTime dt = DateTime.UtcNow;
// dt.ToString("o") -> 2025-04-26T05:32:17.2173477Z
// dt.Kind -> Utc

TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("America/Chicago");
var sf = TimeZoneInfo.ConvertTime(d, tz);
// sf.ToString("o") -> 2025-04-26T00:32:17.2173477
// sf.Kind -> Unspecified

Note that the Unspecified time lacks a time zone offset in the output. You might be tempted to set its Kind to Local, but this is usually not a good idea:

// don't do this
var sfLocal = DateTime.SpecifyKind(sf, DateTimeKind.Local);
sfLocal.ToString("o") -> 2025-04-26T00:32:17.2173477+00:00

The time is correct, but the time zone offset is not. Chicago is -05:00, not +00:00. "Local" in this context is the server's time zone (-00:00).

1That undesired time zone also shows up in the related format strings %K, %z, zz, and zzz above. Again, these show the time zone of the server, not the time zone the value was converted to. Luckily, DateTimeOffset handles this better:

var dto = DateTimeOffset.UtcNow;
var chicagoDto = TimeZoneInfo.ConvertTime(dto, tz);
// dto.ToString("zzz")        --> +00:00
// chicagoDto.ToString("zzz") --> -05:00

Other surprising things

The Ticks property is not agnostic of time zones/kind:

DateTime utc = DateTime.UtcNow;
DateTime local = utc.ToLocalTime(); // don't do this
DateTime unspecified = TimeZoneInfo.ConvertTime(utc, tz);

// utc.Ticks         --> 638812423372173869
// local.Ticks       --> 638812423372173869
// unspecified.Ticks --> 638812243372173869

I guess it makes sense that Ticks would vary here, but I personally would have guessed that it was always in UTC, sort of like Javascript's getTime.

And DateTimeOffset works in the same spirit by factoring in the offset:

// these are the same for DateTimeOffset, but not DateTime
// dto.Ticks        --> 638812423372173827
// chicagoDto.Ticks --> 638812243372173827
//
// and the difference is the same as the time zone offset ✔️:
// (chicagoDto.Ticks - dto.Ticks) / TimeSpan.TicksPerHour --> -5