Introduction

The error "No overload for method ToString takes 1 argument" usually means the compiler does not think you are calling DateTime.ToString(string format). Instead, it thinks you are calling ToString on a value typed as object, dynamic, or some other type that does not expose that overload. The fix is usually to convert the value to DateTime before formatting it.

Why the Error Happens

DateTime has several useful ToString overloads, including one that accepts a format string:

DateTime now = DateTime.Now;
Console.WriteLine(now.ToString("yyyy-MM-dd"));

That compiles because now is statically typed as DateTime.

The problem appears when the value is actually typed as object, which often happens with DataRow, ViewData, loosely typed collections, or older APIs:

object value = DateTime.Now;
Console.WriteLine(value.ToString("yyyy-MM-dd")); // compile error

From the compiler’s perspective, value is just an object, and object.ToString() only has the parameterless version.

Cast or Convert Before Formatting

The most direct fix is to cast the value to DateTime first:

1object value = DateTime.Now;
2
3string text = ((DateTime)value).ToString("yyyy-MM-dd");
4Console.WriteLine(text);

If the source value might not already be a DateTime, use a safer conversion path:

1object value = "2026-03-07";
2
3DateTime date = Convert.ToDateTime(value);
4string text = date.ToString("yyyy-MM-dd");
5Console.WriteLine(text);

This separates conversion from formatting, which usually makes both the code and the failure behavior clearer.

A Common DataRow Example

This error often shows up when reading from DataRow because the indexer returns object.

Problematic code:

string text = row["CreatedAt"].ToString("yyyy-MM-dd");

Corrected version:

DateTime createdAt = (DateTime)row["CreatedAt"];
string text = createdAt.ToString("yyyy-MM-dd");

If you are using the generic Field<T> helper, the code becomes even clearer:

DateTime createdAt = row.Field<DateTime>("CreatedAt");
string text = createdAt.ToString("yyyy-MM-dd");

That is usually the cleanest answer when working with DataTable rows.

Handle Nullable Dates Properly

If the value might be missing, use DateTime? and format it carefully:

1DateTime? createdAt = row.Field<DateTime?>("CreatedAt");
2
3string text = createdAt?.ToString("yyyy-MM-dd") ?? "";
4Console.WriteLine(text);

This avoids exceptions and makes the null-handling rule explicit.

Formatting and Culture

Sometimes the format string is fine, but the culture matters too. In that case, call the overload that accepts both a format string and a format provider:

1using System.Globalization;
2
3DateTime date = DateTime.Now;
4string text = date.ToString("dd/MM/yyyy", CultureInfo.InvariantCulture);

Again, this only works after the value is known to be a DateTime. If the variable is still typed as object, the compiler will not find that overload either.

The same rule applies when the value comes from model binding, JSON, or older framework APIs. The runtime payload may represent a date, but the compile-time type at the call site still determines which overloads the compiler allows you to use.

Common Pitfalls

One common mistake is assuming the runtime value matters more than the compile-time type. Even if the object really contains a DateTime, the compiler only allows methods on the static type it sees.

Another mistake is formatting directly off row["column"], ViewBag, or other weakly typed sources without first converting the value.

Developers also sometimes use Convert.ToDateTime when a strong cast or Field<DateTime> would be clearer and safer. Use the conversion style that matches how certain you are about the input type.

Finally, nullable dates need separate handling. If the source can be missing, format through DateTime? rather than forcing a direct cast.

Summary

• The error happens because the compiler is not seeing a DateTime at the call site.
• 'DateTime.ToString("format") works only after the value is cast or converted to DateTime.'
• 'DataRow and other weakly typed APIs commonly trigger this issue because they return object.'
• Use Field<DateTime> or explicit casts when the source type is known.
• Handle nullable dates separately so formatting logic stays safe and explicit.