CAN logging csv with real timestamp

[haoruizhou]

CAN log messages now use the RTC to obtain real-time Unix epoch timestamps in milliseconds when available. The logger falls back to relative time only if a real timestamp is not set, improving log accuracy and consistency.

By including real-time values in the CSV log file, timestamp consistency is maintained regardless of the transmission method used to load data into the database (radio or the fallback method of existing uploads).

Storage implications: currently each relative timestamp is ~3-7 digits. unix epoch is 13 digits

[yamaan93]

You should wrap the logic for getting the timestamp offset into a function because the way you have it now is really messy.

[haoruizhou]

You should wrap the logic for getting the timestamp offset into a function because the way you have it now is really messy.

feedback addressed in commit 1eb4b35

[yamaan93]

ight we can merge this after i see it working in real life, however I read your PR description and this doesn't actually have any implications for the radio based DAQ, since those would be transmitted by the RPi which has it's own clock and only reads CAN, so it doesn't benefit from these changes really. Though this will make things a little simpler I guess on the parsing side for our legacy system.

[haoruizhou]

ight we can merge this after i see it working in real life, however I read your PR description and this doesn't actually have any implications for the radio based DAQ, since those would be transmitted by the RPi which has it's own clock and only reads CAN, so it doesn't benefit from these changes really. Though this will make things a little simpler I guess on the parsing side for our legacy system.

This is a quality of life update. You are correct. The RPi also need a way to connect to the real time clock too so all the radio messages contains real time stamp too. For the messages that the radio may have missed, we can override it with the csv data since they have the same timestamp from the same clock.