IXXAT: timestamps read 1.5 x wall time plus adapter uptime (misplaced parenthesis in _timeoffset; start tick never captured in vcinpl2)

Start in can/interfaces/ixxat/canlib_vcinpl.py around lines 629 and 705, then compare can/interfaces/ixxat/canlib_vcinpl2.py around lines 735 and 843, focusing on epoch offset setup and CAN_INFO_START handling. Run the provided bus.recv reproduction with IXXAT traffic and verify that timestamps align with time.time while hardware-derived frame spacing remains unchanged.

Describe the bug

On the IXXAT backend every received Message.timestamp reads about 28 years in the future, plus the adapter's uptime. Measured on a USB-to-CAN V2 compact (VCI V4 driver 4.1.264.0, fd=False, python-can 4.6.1, Windows 11, Python 3.12): the first frame after Bus(interface="ixxat", channel=0, bitrate=500000) stamped 2684545240.8 while time.time() read 1789696744.2 — a ratio of 1.5000001. The excess over 1.5 * time.time() grew from 142.4 s to 146.5 s across two opens 4.1 s apart, i.e. it is the adapter's own tick counter since power-up, never rebased.

Two lines cause it, both present on main today:

1. A misplaced parenthesis in the epoch offset, in both backends:

   • can/interfaces/ixxat/canlib_vcinpl.py line 629
   • can/interfaces/ixxat/canlib_vcinpl2.py line 735

   self._timeoffset = start_begin + (start_end - start_begin / 2)
   

   This evaluates to 1.5 * start_begin + start_end instead of the midpoint start_begin + (start_end - start_begin) / 2. Hence the 1.5 x wall-clock epoch.

2. The start tick is never captured in canlib_vcinpl2.py (line 843): the CAN_INFO_START check is an elif sibling of the CAN_MSGTYPE_INFO branch rather than nested inside it, so an INFO message is consumed by the first elif and _starttickoffset stays 0. Every timestamp then carries the adapter's uptime. canlib_vcinpl.py on main has this check nested correctly (line 705); the FD backend does not.

   elif self._message.uMsgInfo.Bits.type == constants.CAN_MSGTYPE_INFO:
       log.info(...)
   # Handle CAN start info message
   elif self._message.abData[0] == constants.CAN_INFO_START:   # never reached for INFO messages
       self._starttickoffset = self._message.dwTime
   

The spacing between frames is correct and hardware-derived (10.014 s of frame time against 10.014 s of wall time over 10 s, never a step backwards, 9 µs resolution), so this is purely the epoch.

To Reproduce

import time, can
bus = can.Bus(interface="ixxat", channel=0, bitrate=500000)
msg = bus.recv(5)
print(msg.timestamp, time.time(), msg.timestamp / time.time())
# 2684545240.8  1789696744.2  1.5000001

Any bus with traffic reproduces it; the ratio of timestamp / time.time() is 1.5 rather than 1.0.

Expected behaviour

Message.timestamp should be Unix time to within the open call, as the other backends provide, with the adapter's own tick spacing preserved.

Additional context

• python-can 4.6.1 (also present on main at the lines cited above)
• IXXAT USB-to-CAN V2 compact, HMS VCI V4 4.1.264.0, Windows 11, Python 3.12
• Working around it downstream by adding one constant settled from the first frame's arrival when the bus's offset lies outside the open call; happy to open a PR for the two one-line fixes if that is welcome.