DateTime.ToString()

wassupy.com

shorthand format strings

dates

d 4/2/2025
D Wednesday, April 2, 2025
m April 2
M April 2
y April 2025
Y April 2025

times

t 12:30 AM
T 12:30:18 AM

combos

f Wednesday, April 2, 2025 12:30 AM
F Wednesday, April 2, 2025 12:30:18 AM
g 4/2/2025 12:30 AM
G 4/2/2025 12:30:18 AM
o 2025-04-02T00:30:18.5828956
r Wed, 02 Apr 2025 00:30:18 GMT
s 2025-04-02T00:30:18
u 2025-04-02 00:30:18Z
U Wednesday, April 2, 2025 12:30:18 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 Wednesday
ddd Wed
dd 02
%d 2

custom time bits

hour

HH 00
%H 0
hh 12
%h 12

minute

mm 30
%m 30

second

ss 18
%s 18

subsecond

%f 5
ff 58
fff 582
ffff 5825
fffff 58252
ffffff 582524
fffffff 5825244

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-02T04:30:18.5830504Z
// dt.Kind -> Utc

TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("America/Chicago");
var sf = TimeZoneInfo.ConvertTime(d, tz);
// sf.ToString("o") -> 2025-04-01T23:30:18.5830504
// 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-01T23:30:18.5830504+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         --> 638791650185830681
// local.Ticks       --> 638791650185830681
// unspecified.Ticks --> 638791470185830681

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