diff --git a/goals/G-126-punkzip-accelerator.md b/goals/G-126-punkzip-accelerator.md
index a00a8048..e42e6b14 100644
--- a/goals/G-126-punkzip-accelerator.md
+++ b/goals/G-126-punkzip-accelerator.md
@@ -171,6 +171,25 @@ working tree; one now exists.
   and stay blocking. Anonymous CreatePipe pipes (Tcl exec, zig build test) are
   synchronous and unaffected.
 
+- Timestamp behaviour on extraction, measured 2026-07-27 (info-zip fixture, stored DOS
+  time 2021-10-06 01:50:08): FILE mtimes are preserved exactly (epoch 1633485008,
+  identical between the current v2.3.0 exe and the old Nov-2024 v2.1.0 exe - no
+  regression through the 0.15/0.16 ports; the set-timestamps-before-write order does
+  not get stomped on Windows). File atimes and DIRECTORY mtimes are NOT preserved
+  (both read as extraction time; the dir case is the long-standing zig limitation the
+  extract output flags with "UNABLE TO SET MTIME ON FOLDER" - zig 0.16 Io still cannot
+  do it: read-only dir handles lack FILE_WRITE_ATTRIBUTES and write-mode dir opens
+  return error.IsDir). PROVEN FIXABLE in punkzip: direct
+  CreateFileW(FILE_FLAG_BACKUP_SEMANTICS, FILE_WRITE_ATTRIBUTES) + SetFileTime on the
+  directory works (verified read-back exact); a proper fix stamps directories in a
+  deferred pass AFTER their contents are extracted, since creating children updates
+  the parent's mtime. SEMANTICS NOTE for the parity suite: punkzip interprets the
+  zone-less DOS timestamp as UTC (deterministic, tz-free, and build->extract
+  roundtrips exactly); bsdtar instead honours Info-ZIP's UT extra field (true UTC),
+  so third-party comparisons can differ by the creator's tz offset (2h on this
+  fixture, made in UTC+2). Compare mtimes via the raw dostime or via punkzip's
+  UTC-interpretation convention, never via a local-time conversion.
+
 ## Progress
 
 - 2026-07-27 upstream zig 0.16.0 port COMPLETE (commit 3b87087 on top of the e9b5b553