packages/odf.js/src/zip.ts pins every zip entry's mtime to a fixed constant:
```ts
const FIXED_ENTRY_MTIME = new Date(Date.UTC(1980, 0, 1, 0, 0, 0));
```
fflate's zipSync (via wzh's DOS-date encoding) reads this Date through its local calendar getters, not UTC. Whenever the invoking process's own local timezone has a negative UTC offset at that specific historical instant, the local calendar date rolls back to 1979-12-31 -- one day below fflate's own accepted DOS-date floor of 1980 -- and zipSync throws `Error: date not in range 1980-2099`.
Reproduced directly:
```
$ node -e 'console.log(new Date(Date.UTC(1980,0,1)).getFullYear(), new Date(Date.UTC(1980,0,1)).getMonth()+1, new Date(Date.UTC(1980,0,1)).getDate())'
TZ=America/New_York -> 1979 12 31
TZ=Pacific/Kiritimati -> 1979 12 31 (Kiritimati was UTC-10:40 before its 1995 date-line move, not its current UTC+14)
TZ=UTC -> 1980 1 1
TZ=Australia/Sydney -> 1980 1 1
```
Any documents.js test that builds an in-memory .odb/.odp/etc via odf.js's zipPackage (e.g. `embeddedHsqldbCachedOdbBytes()` in packages/documents.js/src/test-support/odb.ts) crashes with this error under TZ=America/New_York or TZ=Pacific/Kiritimati specifically -- found incidentally while robustness-testing the fix for #1234 across several ambient TZ values, unrelated to that issue's own worker_threads root cause. Doesn't affect real CI today since GitHub Actions runners default to UTC, but it's a real landmine for anyone running tests locally under an affected zone, or if CI's own default ever changes.
Fix is presumably either building the DOS timestamp from FIXED_ENTRY_MTIME's UTC fields explicitly rather than relying on fflate's local-getter-based encoding, or picking a fixed mtime with enough margin above 1980-01-01 to tolerate any real-world UTC offset (up to UTC+14) rather than sitting exactly on the boundary.
packages/odf.js/src/zip.ts pins every zip entry's mtime to a fixed constant:
```ts
const FIXED_ENTRY_MTIME = new Date(Date.UTC(1980, 0, 1, 0, 0, 0));
```
fflate's zipSync (via wzh's DOS-date encoding) reads this Date through its local calendar getters, not UTC. Whenever the invoking process's own local timezone has a negative UTC offset at that specific historical instant, the local calendar date rolls back to 1979-12-31 -- one day below fflate's own accepted DOS-date floor of 1980 -- and zipSync throws `Error: date not in range 1980-2099`.
Reproduced directly:
```
$ node -e 'console.log(new Date(Date.UTC(1980,0,1)).getFullYear(), new Date(Date.UTC(1980,0,1)).getMonth()+1, new Date(Date.UTC(1980,0,1)).getDate())'
TZ=America/New_York -> 1979 12 31
TZ=Pacific/Kiritimati -> 1979 12 31 (Kiritimati was UTC-10:40 before its 1995 date-line move, not its current UTC+14)
TZ=UTC -> 1980 1 1
TZ=Australia/Sydney -> 1980 1 1
```
Any documents.js test that builds an in-memory .odb/.odp/etc via odf.js's zipPackage (e.g. `embeddedHsqldbCachedOdbBytes()` in packages/documents.js/src/test-support/odb.ts) crashes with this error under TZ=America/New_York or TZ=Pacific/Kiritimati specifically -- found incidentally while robustness-testing the fix for #1234 across several ambient TZ values, unrelated to that issue's own worker_threads root cause. Doesn't affect real CI today since GitHub Actions runners default to UTC, but it's a real landmine for anyone running tests locally under an affected zone, or if CI's own default ever changes.
Fix is presumably either building the DOS timestamp from FIXED_ENTRY_MTIME's UTC fields explicitly rather than relying on fflate's local-getter-based encoding, or picking a fixed mtime with enough margin above 1980-01-01 to tolerate any real-world UTC offset (up to UTC+14) rather than sitting exactly on the boundary.