Cross‑platform DateTime Kind.Unspecified conversion with TimeZoneInfo

Answer

No — TimeZoneInfo.ConvertTime should not reinterpret DateTimeKind.Unspecified as UTC by default, and no DateTimeKind overload is needed. The reliable fix is on the caller side: give the value an explicit Kind with DateTime.SpecifyKind, or switch to DateTimeOffset. The documentation point is valid — the current assumption should be stated plainly so developers stop discovering it in production.

Confirmed behavior

• In .NET Framework and .NET Core / .NET 5+, TimeZoneInfo.ConvertTime(DateTime, TimeZoneInfo) treats a DateTime whose Kind is Unspecified as if it were in TimeZoneInfo.Local — the process's local time zone.
• This rule is identical on Windows and Linux. The cross-platform divergence you see comes from the OS-level zone differing (e.g., a developer machine on a regional zone vs. a container defaulting to UTC), not from the API itself.
• There is no ConvertTime overload accepting a DateTimeKind. Interpretation is controlled entirely by the value's Kind at call time.

Why the default should stay

Changing Unspecified to mean UTC would silently alter results for every existing application that passes local wall-clock values — a classic breaking change with no compile-time signal. An overload taking DateTimeKind would be redundant, because DateTime.SpecifyKind already expresses the same intent without new API surface. The reasonable ask is a documentation clarification recommending DateTimeOffset for instants.

Getting consistent results for UTC-originating log values

If the value represents UTC, stamp it before converting:

DateTime utcValue = DateTime.SpecifyKind(rawValue, DateTimeKind.Utc);
DateTime converted = TimeZoneInfo.ConvertTime(utcValue, targetZone);

Better, carry the instant explicitly so no assumption is ever made:

DateTimeOffset dto = new DateTimeOffset(rawValue, TimeSpan.Zero); // rawValue is UTC
DateTimeOffset convertedDto = TimeZoneInfo.ConvertTime(dto, targetZone);

You can also use TimeZoneInfo.ConvertTimeFromUtc(utcValue, targetZone), which requires a UTC-kind input and throws otherwise — a useful guardrail.

Verification

Run the same snippet on both platforms and compare:

var v = new DateTime(2026, 10, 12, 3, 33, 0, DateTimeKind.Unspecified);
Console.WriteLine(TimeZoneInfo.Local.Id);
Console.WriteLine(TimeZoneInfo.ConvertTime(v, TimeZoneInfo.Utc));
Console.WriteLine(TimeZoneInfo.ConvertTime(DateTime.SpecifyKind(v, DateTimeKind.Utc), TimeZoneInfo.Utc));

If TimeZoneInfo.Local.Id is UTC (common in containers), the first conversion already matches the second; if it is anything else, the first result is offset by the local zone and you must apply SpecifyKind or use DateTimeOffset.