Pekka Klärck

It seems you have encountered [Y2038 problem](https://en.wikipedia.org/wiki/Year_2038_problem). We possibly could workaround the issue like this: ```python try: return time.mktime(dt.timetuple()) + dt.microsecond / 1e6 except OverflowError: now = datetime.now() return time.mktime(now.timetuple())...

Already tested that DST causes problems. This is a better workaround: ```python try: return time.mktime(dt.timetuple()) + dt.microsecond / 1e6 except OverflowError: ok = dt.replace(year=2037) return time.mktime(ok.timetuple()) + ok.microsecond / 1e6...

Any updated to this @juha-ylikoski?

Epoch time is independent on time zones. At a certain time, it's the same everywhere. This was lately discussed as part of #4322 and the docs were enhanced related to...

Notice that the DateTime library in general doesn't support time zones well. The main reason is that the underlying datetime module doesn't support them too well either. The support has...

Yeah, SKIP is a much better status than FAIL with tests that aren't run due to an earlier fatal error. In additions to things already listed in the description, also...

When using the `--dotted` console mode, we actually already now use `x` on console instead of `F` with these failures to separate the "real" failure from others. If using SKIP,...

How to handle `--exitonerror` (#1807) turned out to be a bit tricky: - If there's a parsing error (e.g. an invalid setting) no tests are run and all are marked...

Need to also handle a situation where a fatal error occurs in suite setup specially. Tests in that suite should get FAIL status, not SKIP. Tests in subsequent suite should...

This would be nice enhancement but due to the problems caused by `--exitonerror` this is too big task for RF 5.0. The best way to handle those problems would probably...