In mfer/serialize.go, newTimestampFromTime computes nanoseconds via:
Nanos:int32(t.UnixNano()-(t.Unix()*1000000000)),
time.Time.UnixNano() returns an int64 that overflows for dates before approximately year 1678 or after year 2262. The Go documentation explicitly warns: "The result is undefined if the Unix time in nanoseconds cannot be represented by an int64 (a date before the year 1678 or after 2262). Note that this means the result of calling UnixNano on the zero Time is undefined."
Archival tools may encounter files with very old modification times (e.g., zero time, or dates from early computing history). This would cause a panic.
Note: The ModTime.Timestamp() method in builder.go correctly uses t.Nanosecond() which never panics. Only newTimestampFromTime has this bug.
Fix: Use t.Nanosecond() instead of the manual UnixNano() subtraction, matching the pattern already used in ModTime.Timestamp().
In `mfer/serialize.go`, `newTimestampFromTime` computes nanoseconds via:
```go
Nanos: int32(t.UnixNano() - (t.Unix() * 1000000000)),
```
`time.Time.UnixNano()` returns an `int64` that overflows for dates before approximately year 1678 or after year 2262. The Go documentation explicitly warns: *"The result is undefined if the Unix time in nanoseconds cannot be represented by an int64 (a date before the year 1678 or after 2262). Note that this means the result of calling UnixNano on the zero Time is undefined."*
Archival tools may encounter files with very old modification times (e.g., zero time, or dates from early computing history). This would cause a panic.
Note: The `ModTime.Timestamp()` method in `builder.go` correctly uses `t.Nanosecond()` which never panics. Only `newTimestampFromTime` has this bug.
**Fix:** Use `t.Nanosecond()` instead of the manual `UnixNano()` subtraction, matching the pattern already used in `ModTime.Timestamp()`.
clawbot
self-assigned this 2026-02-08 21:01:33 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
In
mfer/serialize.go,newTimestampFromTimecomputes nanoseconds via:time.Time.UnixNano()returns anint64that overflows for dates before approximately year 1678 or after year 2262. The Go documentation explicitly warns: "The result is undefined if the Unix time in nanoseconds cannot be represented by an int64 (a date before the year 1678 or after 2262). Note that this means the result of calling UnixNano on the zero Time is undefined."Archival tools may encounter files with very old modification times (e.g., zero time, or dates from early computing history). This would cause a panic.
Note: The
ModTime.Timestamp()method inbuilder.gocorrectly usest.Nanosecond()which never panics. OnlynewTimestampFromTimehas this bug.Fix: Use
t.Nanosecond()instead of the manualUnixNano()subtraction, matching the pattern already used inModTime.Timestamp().