Time::Piece and Time::TimeZone compatibility boundary when replacing system TZ with explicit regional offsets

When converting Unix epoch timestamps to regional wall-clock times, Time::Piece delegates localtime to the underlying C library and the process TZ environment variable, making output dependent on the host operating system's time zone database. Time::TimeZone offers explicit regional offset lookups that do not rely on the OS locale, but combining the two approaches raises unresolved questions about daylight saving time consistency. Because Time::Piece is a thin wrapper over C functions, its behavior can differ between POSIX-compliant systems and Windows, and manually applying an offset from Time::TimeZone to a Time::Piece object may not account for the same DST transition rules that the C library would apply. Altering the TZ variable at runtime to influence Time::Piece is also documented as unsafe in threaded Perl applications.

Which documented behavior should govern the boundary when a script replaces system TZ lookups with explicit Time::TimeZone offsets: the C library's transition table or the CPAN module's offset table? How can a multi-threaded Perl program avoid race conditions if it must temporarily adjust the process TZ environment while still using Time::Piece for formatting? Are there version-specific guarantees for Time::Piece and Time::TimeZone that ensure identical DST boundary results across differing OS-level TZ database versions?