Pekka Klärck

I cannot reproduce this problem. The original example didn't show how tests were actually run (please try to make examples [short and self-contained](http://www.sscce.org/)) but I tested that if I have...

I did my testing using the latest Robot code on Python 3.8. The problem was demonstrated using RF 3.0 on Jython 2.7 and that combination certainly can have problems like...

Any new info related to this?

What exactly we need to change to take `datetime` objects into use is still a bit unclear. One thing to consider is should we preserve existing `starttime` and `endtime` attributes...

If someone wonders why we have even created our own timestamp handling functions and didn't use `datetime` to begin with, the reason is that earliest Robot Framework releases supported Python...

Thought about the API bit more and think this would work: 1. Model objects get new `start_time` and `end_time` attributes that contain the actual `datetime` objects (and are `None` by...

We probably should change the formatted timestamps from the current `20220308 16:36:12.123` format to more ISO 8601 compatible format like `2022-03-08 16:36:12.123`. We should use it in logs, reports and...

One smallish thing to decide is the timestamp precision. So far we have used milliseconds but `datetime.now()` uses microsecond precision. Due to Robot's own overhead, I got a feeling microsecond...

Yet another thing to decide is how to handle timezones. Using [datetime terminology](https://docs.python.org/3/library/datetime.html#aware-and-naive-objects), we should decide should timestamps be aware or naive. I believe using naive timestamps is better, because...

Due to changes needed to output.xml, and output.xml being such an important interface between external systems, it's better to do this in RF 6.0. A benefit of waiting for RF...