DateTime.ToString()

wassupy.com

shorthand format strings

dates

d 7/20/2025
D Sunday, July 20, 2025
m July 20
M July 20
y July 2025
Y July 2025

times

t 4:37 AM
T 4:37:26 AM

combos

f Sunday, July 20, 2025 4:37 AM
F Sunday, July 20, 2025 4:37:26 AM
g 7/20/2025 4:37 AM
G 7/20/2025 4:37:26 AM
o 2025-07-20T04:37:26.9240725
r Sun, 20 Jul 2025 04:37:26 GMT
s 2025-07-20T04:37:26
u 2025-07-20 04:37:26Z
U Sunday, July 20, 2025 4:37:26 AM

custom date bits

era

%g AD
gg AD

year

yyyyy 02025
yyyy 2025
yyyy 2025
yy 25
y July 2025

month

MMMM July
MMM Jul
MM 07
%M 7

day

dddd Sunday
ddd Sun
dd 20
%d 20

custom time bits

hour

HH 04
%H 4
hh 04
%h 4

minute

mm 37
%m 37

second

ss 26
%s 26

subsecond

%f 9
ff 92
fff 924
ffff 9240
fffff 92407
ffffff 924075
fffffff 9240757

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-07-20T08:37:26.9247274Z
// dt.Kind -> Utc

TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("America/Chicago");
var sf = TimeZoneInfo.ConvertTime(d, tz);
// sf.ToString("o") -> 2025-07-20T03:37:26.9247274
// 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-07-20T03:37:26.9247274+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         --> 638885974469247905
// local.Ticks       --> 638885974469247905
// unspecified.Ticks --> 638885794469247905

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        --> 638885974469247849
// chicagoDto.Ticks --> 638885794469247849
//
// and the difference is the same as the time zone offset ✔️:
// (chicagoDto.Ticks - dto.Ticks) / TimeSpan.TicksPerHour --> -5