DateTime.ToString()

wassupy.com

shorthand format strings

dates

d 7/2/2025
D Wednesday, July 2, 2025
m July 2
M July 2
y July 2025
Y July 2025

times

t 11:40 PM
T 11:40:16 PM

combos

f Wednesday, July 2, 2025 11:40 PM
F Wednesday, July 2, 2025 11:40:16 PM
g 7/2/2025 11:40 PM
G 7/2/2025 11:40:16 PM
o 2025-07-02T23:40:16.4699425
r Wed, 02 Jul 2025 23:40:16 GMT
s 2025-07-02T23:40:16
u 2025-07-02 23:40:16Z
U Wednesday, July 2, 2025 11:40:16 PM

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 Wednesday
ddd Wed
dd 02
%d 2

custom time bits

hour

HH 23
%H 23
hh 11
%h 11

minute

mm 40
%m 40

second

ss 16
%s 16

subsecond

%f 4
ff 46
fff 469
ffff 4699
fffff 46998
ffffff 469985
fffffff 4699850

miscellaneous bits

date separator

%/ /

time separator

%: :

AM/PM

%t P
tt PM

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-03T03:40:16.4705581Z
// dt.Kind -> Utc

TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("America/Chicago");
var sf = TimeZoneInfo.ConvertTime(d, tz);
// sf.ToString("o") -> 2025-07-02T22:40:16.4705581
// 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-02T22:40:16.4705581+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         --> 638871108164706337
// local.Ticks       --> 638871108164706337
// unspecified.Ticks --> 638870928164706337

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