DateTime.ToString()

wassupy.com

shorthand format strings

dates

d 7/4/2025
D Friday, July 4, 2025
m July 4
M July 4
y July 2025
Y July 2025

times

t 1:18 AM
T 1:18:17 AM

combos

f Friday, July 4, 2025 1:18 AM
F Friday, July 4, 2025 1:18:17 AM
g 7/4/2025 1:18 AM
G 7/4/2025 1:18:17 AM
o 2025-07-04T01:18:17.4302994
r Fri, 04 Jul 2025 01:18:17 GMT
s 2025-07-04T01:18:17
u 2025-07-04 01:18:17Z
U Friday, July 4, 2025 1:18:17 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 Friday
ddd Fri
dd 04
%d 4

custom time bits

hour

HH 01
%H 1
hh 01
%h 1

minute

mm 18
%m 18

second

ss 17
%s 17

subsecond

%f 4
ff 43
fff 430
ffff 4306
fffff 43065
ffffff 430655
fffffff 4306551

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-04T05:18:17.4308562Z
// dt.Kind -> Utc

TimeZoneInfo tz = TimeZoneInfo.FindSystemTimeZoneById("America/Chicago");
var sf = TimeZoneInfo.ConvertTime(d, tz);
// sf.ToString("o") -> 2025-07-04T00:18:17.4308562
// 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-04T00:18:17.4308562+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         --> 638872030974308834
// local.Ticks       --> 638872030974308834
// unspecified.Ticks --> 638871850974308834

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