[9.3.0] Record PackageZipper timestamps in the local time zone (from #30592) (#31180) ### Description `PackageZipper` stamps every entry with a fixed instant of 1980-01-01 00:00:00 UTC, but DOS timestamps carry no time zone. The recorded date therefore depends on the zone of the machine that runs the tool. Behind UTC, that instant falls before the DOS epoch and is not representable at all, which also affects Bazel's own build: ``` ERROR: .../src/BUILD:293:13: Building src/package_jdk_minimal.zip failed: (Exit 1): package_zipper failed Exception in thread "main" java.lang.IllegalArgumentException: 1979-12-31 16:00:00 is not representable in the DOS time format. It must be in the range 1980-01-01 00:00:00 to 2107-12-31 23:59:59 at com.google.devtools.build.zip.ZipUtil.unixToDosTime(ZipUtil.java:168) at com.google.devtools.build.zip.LocalFileHeader.create(LocalFileHeader.java:96) at com.google.devtools.build.zip.PackageZipper.writeBytesEntry(PackageZipper.java:212) ``` Ahead of UTC the instant is representable, but records a later time of day: in `Europe/Berlin` the packed field is `0x00210800` (01:00:00) where a UTC machine writes `0x00210000` (00:00:00). The archive bytes differ by builder time zone, which defeats hermeticity. Fixes #31165. ### Motivation ### Build API Changes No ### Checklist - [x] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes RELNOTES: None Closes #30592. PiperOrigin-RevId: 959815070 Change-Id: Ib95a2cd9a0cbb40f1cc0a6264de3621e42045e2f <!-- Thank you for contributing to Bazel! Please read the contribution guidelines: https://bazel.build/contribute --> ### Description <!-- Please provide a brief summary of the changes in this PR. --> ### Motivation <!-- Why is this change important? Does it fix a specific bug or add a new feature? If this PR fixes an existing issue, please link it here (e.g. "Fixes #1234"). --> ### Build API Changes <!-- Does this PR affect the Build API? (e.g. Starlark API, providers, command-line flags, native rules) If yes, please answer the following: 1. Has this been discussed in a design doc or issue? (Please link it) 2. Is the change backward compatible? 3. If it's a breaking change, what is the migration plan? --> No ### Checklist - [ ] I have added tests for the new use cases (if any). - [ ] I have updated the documentation (if applicable). ### Release Notes <!-- If this is a new feature, please add 'RELNOTES[NEW]: <description>' here. If this is a breaking change, please add 'RELNOTES[INC]: <reason>' here. If this change should be mentioned in release notes, please add 'RELNOTES: <reason>' here. --> RELNOTES: None Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
{Fast, Correct} - Choose two
Build and test software of any size, quickly and reliably.
Speed up your builds and tests: Bazel rebuilds only what is necessary. With advanced local and distributed caching, optimized dependency analysis and parallel execution, you get fast and incremental builds.
One tool, multiple languages: Build and test Java, C++, Android, iOS, Go, and a wide variety of other language platforms. Bazel runs on Windows, macOS, and Linux.
Scalable: Bazel helps you scale your organization, codebase, and continuous integration solution. It handles codebases of any size, in multiple repositories or a huge monorepo.
Extensible to your needs: Easily add support for new languages and platforms with Bazel's familiar extension language. Share and re-use language rules written by the growing Bazel community.
Follow our tutorials:
To report a security issue, please email security@bazel.build with a description of the issue, the steps you took to create the issue, affected versions, and, if known, mitigations for the issue. Our vulnerability management team will respond within 3 working days of your email. If the issue is confirmed as a vulnerability, we will open a Security Advisory. This project follows a 90 day disclosure timeline.
See CONTRIBUTING.md
