PowerShell has no inbox cmdlet for converting datetimes between arbitrary time zones

Answer to the three sub‑questions

1. Is there an inbox way to translate Windows zone IDs to IANA names and back?

Confirmed: Neither Windows PowerShell 5.1 nor PowerShell 7 ship a documented API that maps a Windows zone ID (e.g. W. Europe Standard Time) to an IANA name (e.g. Europe/Berlin) or vice‑versa. The mapping is maintained in the Unicode CLDR data and is normally consumed by third‑party libraries such as TimeZoneConverter or NodaTime. If a dependency cannot be added, the only inbox solution is to maintain a small, explicit lookup table for the zones your scripts actually use.

2. Do recent PowerShell 7 builds on Windows resolve IANA IDs through .NET’s ICU support, or is it version‑ and OS‑dependent?

Confirmed: IANA ID resolution on Windows under PowerShell 7 is not guaranteed by PowerShell itself; it depends on the underlying .NET runtime and the Windows build. .NET 6+ can resolve IANA IDs when compiled with ICU support, but the feature is optional and may be disabled on some Windows installations. The safest approach is to probe once at startup:

try {
    [System.TimeZoneInfo]::FindSystemTimeZoneById('Europe/Berlin') | Out-Null
    $ianaSupported = $true
} catch [System.TimeZoneNotFoundException] {
    $ianaSupported = $false
}

If $ianaSupported is $false, fall back to a Windows‑ID lookup or a third‑party library.

3. Which identifier scheme degrades more gracefully when the OS tz database is outdated for historical dates?

Confirmed: Neither scheme is inherently more robust. Windows uses the registry‑based tz data that is updated only with Windows cumulative updates, while Unix/macOS use the IANA tzdata package that is updated more frequently through package managers. Outdated data in either system will produce incorrect historical offsets. Operationally, an up‑to‑date Linux host is more likely to have the latest tzdata, but the choice of scheme should be driven by the target platform’s update cadence rather than an intrinsic property of the identifier.

Practical pattern for cross‑edition conversion

Use [System.TimeZoneInfo] for the actual conversion. Construct DateTime or DateTimeOffset objects with a known Kind (preferably DateTimeKind.Utc or DateTimeOffset) and pass them to ConvertTime or ConvertTimeBySystemTimeZoneId. Avoid relying on Get-Date -AsUTC (PowerShell 7.1+) in shared scripts; use [datetime]::UtcNow or DateTimeOffset.UtcNow instead.

Before shipping, validate the conversion on the exact target runtime:

• Confirm that ConvertTimeBySystemTimeZoneId works with a Windows ID on PowerShell 5.1.
• Probe IANA ID support on the PowerShell 7 build you plan to run.
• Record $PSVersionTable.PSVersion and the OS description to document the environment.