PcanBus adds boottimeEpoch to PCAN-Basic timestamps that are already UTC epoch on Linux #2108

On Linux, PCAN-Basic returns frame timestamps that are already UTC epoch. PcanBus._recv_internal adds boottimeEpoch on top of them, so every frame comes back at roughly twice the real epoch (~3.57e9 s against ~1.79e9 s).

# can/interfaces/pcan/pcan.py, _recv_internal
if self._can_protocol is CanProtocol.CAN_FD:
    timestamp = boottimeEpoch + (pcan_timestamp.value / (1000.0 * 1000.0))
else:
    timestamp = boottimeEpoch + (...)

Both branches add the offset unconditionally. The file's only platform checks, IS_WINDOWS and IS_LINUX, govern event-based waiting, not this. On Windows the driver counts from driver start, so adding boot time is correct there; on Linux it is added twice.

It only shows when the optional uptime package is installed. Without it boottimeEpoch is 0 and the timestamps are right on Linux by accident -- which is probably why this has gone unnoticed.

Nothing raises. The frames arrive and decode correctly and carry a plausible float, so it surfaces much later as a test that sees a dead bus: every frame falls outside every time window the test builds.

Platform: Linux, PCAN-USB, python-can 4.6.1, uptime installed.
Expected: msg.timestamp is UTC epoch seconds, as on other backends.
Actual: about twice that.
A fix needs to know whether the driver's clock is epoch-based or boot-relative. On Linux PCAN-Basic reports epoch, so the offset should not be added there.