Bug: newTimestampFromTime panics on dates outside ~1678-2262 due to UnixNano overflow #15

New Issue

clawbot · 2026-02-08T21:01:33+01:00

clawbot commented

2026-02-08 21:01:33 +01:00

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

clawbot referenced a pull request that will close this issue

2026-02-08 21:06:23 +01:00

Fix newTimestampFromTime panic on extreme dates (closes #15) #20

Sign in to join this conversation.

No Label

No Milestone

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: sneak/mfer#15