csharp dotnet datetime culture

Why Does DateTime.ToString() Differ on Windows and Linux?

A C# date can print differently across machines. Check culture, DateTime.Kind, time zone, and ICU/NLS, then use explicit formatting for reliable logs and APIs.

· Mohammed Aquib Ansari

You log a date in development, deploy the same .NET code to a Linux server, and the string changes. It might switch day and month order, use a different separator, add a different AM/PM marker, or show a different UTC offset. The date formatting call may be doing exactly what you asked: following the environment’s culture and time-zone settings.

The quickest way to debug this is to separate the value, the format, the culture, and the time zone. These are related, but they answer different questions.

1. Check the current culture

Without an IFormatProvider, ToString() and many format strings use CultureInfo.CurrentCulture. The "d" specifier means “short date in this culture,” not “use the same characters everywhere.” A machine or request running under a different culture can therefore print the same value differently.

using System.Globalization;

var date = new DateTime(2026, 9, 27, 14, 5, 0);

Console.WriteLine($"Current culture: {CultureInfo.CurrentCulture.Name}");
Console.WriteLine($"Default: {date}");
Console.WriteLine($"Short date: {date:d}");
Console.WriteLine($"US: {date.ToString("d", new CultureInfo("en-US"))}");
Console.WriteLine($"UK: {date.ToString("d", new CultureInfo("en-GB"))}");

The last two calls choose a culture explicitly. For a user-facing date, choose the user’s intended culture. For a machine-readable value, use a stable format and CultureInfo.InvariantCulture.

string stableDate = date.ToString("yyyy-MM-dd", CultureInfo.InvariantCulture);
// 2026-09-27

MM is month and mm is minute. A typo such as yyyy-mm-dd can look like a machine difference when it is actually a format-string mistake.

2. Inspect DateTime.Kind and the machine’s time zone

DateTime can be Utc, Local, or Unspecified. That affects time-zone formatting. The custom K specifier emits Z for UTC, a local offset for Local, and no time-zone suffix for Unspecified. A DateTime with an unspecified kind does not suddenly become UTC because you print it with a Z literal.

using System.Globalization;

var utc = new DateTime(2026, 9, 27, 14, 5, 0, DateTimeKind.Utc);
var unknown = new DateTime(2026, 9, 27, 14, 5, 0, DateTimeKind.Unspecified);

Console.WriteLine($"Local zone: {TimeZoneInfo.Local.Id}");
Console.WriteLine($"UTC kind: {utc.Kind}; output: {utc.ToString("O", CultureInfo.InvariantCulture)}");
Console.WriteLine($"Unknown kind: {unknown.Kind}; output: {unknown.ToString("O", CultureInfo.InvariantCulture)}");

The UTC value ends with Z; the unspecified value has no offset. If you need to carry a known offset, DateTimeOffset makes that offset part of the value:

var eventTime = new DateTimeOffset(
    2026, 9, 27, 14, 5, 0, TimeSpan.FromMinutes(330));

Console.WriteLine(eventTime.ToString("O", CultureInfo.InvariantCulture));
// 2026-09-27T14:05:00.0000000+05:30

This records the offset, though an offset alone is not a named time zone with future daylight-saving rules. For display in a particular region, convert using the intended time zone and then format for the reader.

3. Check the globalization data and .NET version

Culture data can also differ between environments. Modern .NET commonly uses ICU globalization data; Windows can be configured to use NLS, and runtime/OS/ICU versions can change particular patterns or punctuation. Specifying en-US removes the current-culture variable, but it does not promise byte-for-byte identical localized text across every runtime and culture-data version.

For a reproducible bug report, record:

using System.Globalization;

Console.WriteLine($"Runtime: {Environment.Version}");
Console.WriteLine($"Culture: {CultureInfo.CurrentCulture.Name}");
Console.WriteLine($"UI culture: {CultureInfo.CurrentUICulture.Name}");
Console.WriteLine($"Local zone: {TimeZoneInfo.Local.Id}");
Console.WriteLine($"Short-date pattern: {CultureInfo.CurrentCulture.DateTimeFormat.ShortDatePattern}");

Also record the OS, the original DateTime or DateTimeOffset value, its Kind or offset, and the exact format string. In an ASP.NET Core application, inspect the culture for the request that produced the output rather than assuming every request has the same culture.

Which format should you use?

PurposeRecommended approach
Show a date to a personUse their intended CultureInfo and an appropriate standard or custom format.
Store or exchange a timestampUse DateTimeOffset or an explicitly UTC value; serialize with a round-trip representation such as ToString("O", CultureInfo.InvariantCulture), or use a proper serializer.
Write a stable date-only identifierUse an explicit invariant pattern such as yyyy-MM-dd, after deciding what the date means in your domain.
Compare valuesCompare date/time values, not localized display strings.

The round-trip "O" format preserves the offset for DateTimeOffset and represents DateTime.Kind in its output. It is a better starting point for logs and interchange than a culture-dependent "d", "g", or default ToString() call.

A quick way to test a suspicious format

Open the ByteKiln .NET Format String Tester. Enter the same value and format string, switch among its supported cultures, and compare DateTime with DateTimeOffset. It is a browser-side reimplementation checked against .NET 8 reference cases, not a live .NET runtime. Use it to narrow down the format and culture, then confirm the final behavior in your application’s actual runtime, OS, globalization mode, and time zone.

If you have a Unix timestamp rather than a formatted date, use the Unix Timestamp Converter to check its UTC value and display zone before comparing strings.

If the problem began after deployment, start by logging CurrentCulture, the value’s Kind or offset, and TimeZoneInfo.Local.Id. Those three observations usually explain more than changing the format string at random.

References