Pin zip entry timestamps to 1980-01-01 to match Excel#1755
Open
ken-swyfft wants to merge 1 commit intonissl-lab:masterfrom
Open
Pin zip entry timestamps to 1980-01-01 to match Excel#1755ken-swyfft wants to merge 1 commit intonissl-lab:masterfrom
ken-swyfft wants to merge 1 commit intonissl-lab:masterfrom
Conversation
Excel sets all zip entry timestamps to the DOS epoch minimum (1980-01-01 00:00:00). NPOI was using DateTime.Now, which made output non-deterministic and caused flaky CI failures in Bug56468 when two consecutive writes of the same workbook straddled a 2-second DOS time boundary. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Member
|
/oc |
Contributor
|
Summary: PR to fix non-deterministic zip timestamps in XLSX files by pinning all |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

Summary
This is to fix a flaky
Bug56468test that would periodically fail when doing a byte-by-byte comparison with two files saved with the exact same data. The issue is that the zip entries have timestamps, and if the test passes a two-second DOS timestamp accuracy, the two files wouldn't be exactly the same. This fixes that flaky test by:1980-01-01 00:00:00(the DOS epoch minimum), matching Excel's behaviorZipHelper.ZipEntryTimestampconstant used across all 5ZipEntrycreation sites in OPC packagingBackground
Excel sets all zip entry timestamps inside
.xlsxfiles to1980-01-01 00:00:00. NPOI was usingDateTime.Now(SharpZipLib's default), which meant:Bug56468(which asserts byte-identical output from consecutive writes) failed intermittently in CI under loadThis matches how other xlsx libraries handle it (e.g., XlsxWriter adopted the same fix after inspecting Excel-generated files). Apache POI added similar deterministic timestamp support in v5.4.0 via
SOURCE_DATE_EPOCH.Changed files
openxml4Net/OPC/Internal/ZipHelper.csZipEntryTimestampconstant; applied toGetCorePropertiesZipEntryopenxml4Net/OPC/Internal/Marshallers/ZipPartMarshaller.csopenxml4Net/OPC/Internal/ZipContentTypeManager.cs[Content_Types].xmlentryopenxml4Net/OPC/Internal/Marshallers/ZipPackagePropertiesMarshaller.csooxml/XSSF/Streaming/SXSSFWorkbook.csTest plan
Bug56468passes (20/20 runs in isolation)TestCellIterationOrderWithSparseColumnsfailure from Replace SortedDictionary with Dictionary in HSSFRow, XSSFRow and SXSSFRow #1753)🤖 Generated with Claude Code