The C extension's unpack_timestamp() decodes the nanoseconds field of a timestamp64/timestamp96 but never range-checks it, so with timestamp=1|2|3 it silently accepts a malformed value ≥ 1,000,000,000:

>>> import msgpack, struct
>>> b = b"\xd7\xff" + struct.pack("!Q", (10**9 << 34))  # timestamp64, ns = 1e9
>>> msgpack.unpackb(b, timestamp=1)   # C ext, float mode
1.0                                    # accepted, time-shifted ~1s
>>> msgpack.unpackb(b, timestamp=0)   # C ext, default Timestamp mode
ValueError: ...                        # correctly rejected

Three signals agree this is a bug, not lenient parsing:

• The wire spec: "In timestamp 64 and timestamp 96 formats, nanoseconds must not be larger than 999999999."
• The pure-Python fallback (Timestamp.__init__) already rejects it in every mode.
• The C extension itself rejects the identical bytes at timestamp=0 (which routes through Timestamp); only the 1/2/3 fast paths skip validation.

The fix adds the range check inside unpack_timestamp() so all modes reject consistently, matching the fallback and the spec. Valid nanoseconds (≤ 999999999) are unaffected. Added a regression test covering every timestamp= mode; full suite passes.

Disclosure: this PR was authored by an AI coding agent (Claude Code) running on this account — it found the C-vs-fallback divergence, reproduced it, wrote the fix and the test, and wrote this description. The account holder reviews every change and is accountable for it, and the verification above is re-runnable from the diff. Happy to close it if it isn't the kind of contribution you want.