TTimeZone.Local versus IANA tzdata wrapper for historic Delphi date conversion?

Direct Answer

Use an IANA tzdata wrapper (such as the TZDB library or ICU bindings) for any conversion that must reflect historical daylight-saving rules. TTimeZone.Local on Windows only applies the current rule set, so a 1995 timestamp in a region that later changed its DST policy will return the wrong offset. On POSIX, TTimeZone delegates to the system zoneinfo file, which is accurate only if the OS package is up to date — something you cannot control at deploy time. The two approaches can coexist safely in the same process provided you keep their identifier spaces separate and map Windows zone IDs to IANA IDs explicitly.

Why TTimeZone.Local Fails for Historical Dates on Windows

The RTL calls GetDynamicTimeZoneInformation or GetTimeZoneInformationForYear. Both APIs expose a single rule pair (standard/daylight transition) for the queried year, but Windows does not ship a full transition history in the registry. The registry key HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Time Zones stores only the current rule set. Consequently, TTimeZone.Local.GetUtcOffset(EncodeDateTime(1995,7,1,12,0,0,0)) returns \"what the current rules would produce for July 1\", not the offset that was actually in effect in 1995.

How IANA tzdata Wrappers Provide Deterministic Offsets

Libraries such as Eric Grange's TZDB or ICU4D/ICU via Delphi bindings embed a specific IANA tzdata release (e.g., 2024a). They parse the compiled zoneinfo binary (or the source .zi file) and build complete transition tables for every IANA zone ID (America/Sao_Paulo, Europe/London, etc.). A call like TZDB.GetUtcOffset('America/Sao_Paulo', UTCDateTime) walks the historical transitions and returns the offset that was legally in force at that instant, independent of the host OS.

Using Both Together Safely

1. Reserve TTimeZone for \"now\" UI. Displaying the current local time, formatting Now, or getting the OS-configured zone name are legitimate uses.
2. Route all archival/calculation logic through the IANA wrapper. Any timestamp that may predate a rule change (audit logs, scheduling, billing) should be converted with the wrapper.
3. Map identifiers once at startup. Windows zones (\"E. South America Standard Time\") do not map 1:1 to IANA zones. Load the CLDR windowsZones.xml supplemental data (available from unicode.org) and build a TDictionary for the zones your application actually uses.
4. Never pass a TTimeZone.TTimeZoneInfo instance to code expecting an IANA zone object. They are incompatible types.

Practical Verification Step

Create a test console project targeting the zone in question (e.g., Brazil). Compare:

var
  UTC: TDateTime := EncodeDateTime(1995,7,1,12,0,0,0);
  WinOffset: Integer := TTimeZone.Local.GetUtcOffset(UTC); // minutes
  IANAOffset: Integer := TZDB.GetUtcOffset('America/Sao_Paulo', UTC); // minutes
begin
  Writeln('Windows offset: ', WinOffset);
  Writeln('IANA offset:    ', IANAOffset);
end.

If the two numbers differ, the Windows result is historically incorrect for that date.

One Diagnostic Detail Needed

Which specific Windows timezone identifier (TTimeZone.Local.Id value) is your application configured to use? The mapping to an IANA zone is not always unique (one Windows zone can cover multiple IANA zones with different histories), so the exact ID determines whether a single IANA zone suffices or whether you need user disambiguation.