TimeZoneInfo IANA ID support since .NET 6: which time zone source should a cross-platform app standardize on?

Since .NET 6, TimeZoneInfo.FindSystemTimeZoneById accepts IANA IDs like America/Los_Angeles on all platforms, including Windows. On Windows, however, the runtime translates the IANA ID through a built-in mapping table to a Windows time zone key, and that table is fixed at the runtime's build time. On Linux and macOS the same call resolves against the operating system's tzdata, which typically carries full historical transition rules.

We are standardizing a service that runs in both Windows and Linux containers on .NET 8, and we need to store and convert timestamps going back several decades. The uncertainty is whether a single IANA-ID-based code path behaves identically on both hosts, given that Windows data may lack pre-1970 rules and the mapping table may lag current IANA tzdata releases. The alternative is taking a dependency on a converter package that ships its own tzdata copy, but that adds a second source of truth to keep updated.

Is the built-in IANA mapping on Windows documented as complete for current zones, or are there known unmapped IDs we should enumerate? For historical conversions, does the Windows-resolved zone produce different offsets than the Linux tzdata-resolved zone for the same IANA ID? Is there a supported way to detect at runtime which tzdata version the mapping reflects?