`zipfile` and `tarfile` docs should cover local timezone impact on entry timestamps

In a project that aims to emit reproducible archives, tar.xz archives were working as expected, but zip archives were ending up with timestamp discrepancies between local builds in AEST (UTC+10) and CI builds in UTC.

I eventually tracked this down to differing timestamp handling conventions in tarfile and zipfile (these conventions aren't unique to Python, so we can't readily eliminate the discrepancy, we can only document it):

• tarfile uses the timestamps as they are, so if the filesystem stores timestamps in UTC (as most common filesystems other than FAT/FAT32/VFAT will do), they will be added to the file as UTC. If the filesystem stores local time, it will still be used without modification, but will probably be interpreted as UTC when the archive is extracted
• zipfile explicitly interprets the filesystem timestamps with time.localtime, so they will be added to the file as local time by default. If the filesystem already uses local time, the timezone offset will be applied a second time (potentially resulting in a stored modification time in the future for local timezones with a positive offset from UTC)

tarfile has an additional timezone related complication in that some compression formats (at least gzip) include a file creation time header: https://github.com/python/cpython/issues/75707

Discourse thread: https://discuss.python.org/t/tarfile-vs-zipfile-timezone-discrepancy-in-handling-modification-times/61016

Linked PRs

• gh-155195

Bắt đầu bằng cách xem lại tài liệu về zipfile và tarfile cùng với chuỗi thảo luận Discourse được liên kết và vấn đề timestamp của gzip. Ghi lại cách việc xử lý múi giờ cục bộ ảnh hưởng đến timestamp của các mục trong cả hai định dạng lưu trữ, bao gồm cả vấn đề phức tạp bổ sung liên quan đến thời gian tạo của gzip; PR gh-155195 được liên kết cho thấy công việc này đã được tiến hành.