Write 3 ms digits to ascii to resolve CANoe bug

[j-c-cook]

• The ascii writer will now only write 3 micro second decimal places to a log file.
• The ascii format currently is not setup to append. I recenly added in **options to the logger script. **options are only required for
  the rolling logger.

closes #1315
closes #1357

[codecov]

Codecov Report

Merging #1362 (44b0489) into develop (88fc8e5) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop    #1362      +/-   ##
===========================================
+ Coverage    66.13%   66.18%   +0.05%     
===========================================
  Files           86       86              
  Lines         9004     9006       +2     
===========================================
+ Hits          5955     5961       +6     
+ Misses        3049     3045       -4     

[j-c-cook]

@zariiii9003 ready for review.

[j-c-cook]

@zariiii9003 I believe this is a fix for the bug described in #1315.

[j-c-cook]

At a glance, I'm not sure how the test failure of mypy --python-version 3.8 . has to do with these minor changes. The datetime documentation says strftime returns a string, and I have operated on it with string compatible functions (index and replace).

[zariiii9003]

At a glance, I'm not sure how the test failure of mypy --python-version 3.8 . has to do with these minor changes. The datetime documentation says strftime returns a string, and I have operated on it with string compatible functions (index and replace).

I just ran into this issue, too. It's weird because nothing changed. I'll try to fix it.

[zariiii9003]

Should be fixed in develop.

[Tian-Jionglu]

@j-c-cook as mentioned in #1357, script can_logconvert.py makes logged datetime in converted asc file as converting datetime. Does anyone else also think it is weird?

[zariiii9003]

@j-c-cook as mentioned in #1357, script can_logconvert.py makes logged datetime in converted asc file as converting datetime. Does anyone else also think it is weird?

I'm not sure what you mean, could you give an example? Or attach the files maybe?

[Tian-Jionglu]

See logs header below:

• ascii logged by python-can can_logger.py

date Thu Aug 04 03:17:23.124 PM 2022
base hex  timestamps absolute
internal events logged
Begin Triggerblock Thu Aug 04 03:17:23.120 PM 2022

• ascii logged by CANalyzer

date Mon Aug 15 09:32:44.632 am 2022
base hex  timestamps absolute
internal events logged
// version 11.0.0
Begin Triggerblock Mon Aug 15 09:32:44.632 am 2022

• ascii converted by python-can can_logconvert.py

date Sat Aug 13 09:09:58.794 AM 2022
base hex  timestamps absolute
internal events logged
Begin Triggerblock Thu Aug 04 12:44:31.611 PM 2022

We can see that in log from CANalyzer, log datetime is the same as trigger beginning datetime.
But in python-can these two datetimes are different, this differs a lot when using logconvert.

[Tian-Jionglu]

@zariiii9003, what's your opinion?

[zariiii9003]

I see what you mean now. Technically the current implementation is correct, The header tells when the file was created and the triggerblock tells the timestamp of the first message.

But i'd like to hear other opinions on this.