python-can doesn't appear to be using hardware timestamps with socketcan

### Describe the bug

### To Reproduce

Run two captures at the same time, one using candump with hardware timestamps :

`candump -ta -H can1
`

The other utilising python-can e.g. logger :

`python -m can.logger -c can1
`

If you then dump the output into a spreadsheet and compare frames, the output is quite different. For example, on a cyclic message on our hardware, I can see the cycle with `candump -H` is stable +/- 5 microseconds. With the timestamps from python-can the variance seems to be +/- 900 microseconds.

### Expected behavior

The python can docs say :

> The timestamp field in a CAN message is a floating point number representing when the message was received since the epoch in seconds. Where possible this will be timestamped in hardware.

So I'd have expected the hardware timestamps to have been enabled as with `candump -H`.

### Additional context

OS and version: Debian 12 (6.1.112-1)
Python version: 3.11
python-can version: 4.4.2
python-can interface/s (if applicable): Peak PCAN-USB X6

We're using the standard kernel drivers not peak's custom drivers.

Traceback and logs