Configuring TimeZoneInfo.ConvertTime to Accept an Explicit Source Time Zone for Unspecified DateTime Values

Answer the Exact Question

Yes. Use the three‑parameter overload of TimeZoneInfo.ConvertTime that accepts a source and a destination TimeZoneInfo. It treats an Unspecified DateTime as if it belongs to the supplied source zone, converts it to the destination zone, and returns a DateTime with Kind=Unspecified. This preserves the original zone’s identity for future conversions.

Likely Explanation

The ConvertTime(DateTime, TimeZoneInfo, TimeZoneInfo) overload was added in .NET 3.5. It ignores the DateTime.Kind when a source zone is supplied, so you can pass an Unspecified value representing, say, Eastern Standard Time, and get the correct UTC value without touching the Kind property.

Confirmed Facts

• Available in .NET 3.5 and later.
• Signature: public static DateTime ConvertTime(DateTime dateTime, TimeZoneInfo sourceTimeZone, TimeZoneInfo destinationTimeZone).
• Returns DateTimeKind.Unspecified regardless of input kind.
• Throws ArgumentException if the local time is ambiguous or invalid for the source zone unless you handle it with IsAmbiguousTime or IsInvalidTime first.
• If targeting .NET 2.0 or earlier, the overload does not exist; you must compute the offset manually.

Steps for Your Scenario

1. Identify the source zone: var sourceZone = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
2. Call the three‑parameter overload: var utc = TimeZoneInfo.ConvertTime(myUnspecified, sourceZone, TimeZoneInfo.Utc);
3. Store the sourceZone.Id (or the TimeZoneInfo itself) alongside the DateTime for future round‑trips.
4. When you need to convert back, use the same overload: TimeZoneInfo.ConvertTime(utc, TimeZoneInfo.Utc, sourceZone);.

Extension‑Method Wrapper (Backward‑Compatible)

For projects that must support .NET 2.0, create an extension method that:

• Checks for the presence of the three‑parameter overload via reflection.
• If available, forwards the call.
• Otherwise, falls back to sourceZone.GetUtcOffset(dateTime) and adds/subtracts that offset, handling ambiguous/invalid times manually.

Alternative: DateTimeOffset + Zone ID Pair

Store the DateTimeOffset (which keeps the offset) together with the zone ID. This gives you the offset at that instant and the zone for future DST changes, but you still need the zone ID for correct historical conversions.

Missing Diagnostic Detail

Which .NET framework version are you targeting? If you are constrained to .NET 2.0, the three‑parameter overload is unavailable and you must use the manual offset approach.