Unit test test_parse_time_with_now_and_utc fails around DST change

[fedepell]

Very minor but reporting as it was creating me headaches, running tests just exactly today.

It seems to me that the test_parse_time_with_now_and_utc test will fail if run just on the day of DST change (ie. today) or the day before as they are doing comparisons with +/- 1 day and a hardcoded seconds difference value, which is incorrect if the DST happens between the two cases compared.

Specifically today (last night DST changed here) I see failing those tests:

                                ('now - 1 day 100 seconds',-86500),
                                ('NOW - 1D 10H 1MIN 10S', -122470)]:

Probably yesterday (so just before DST change) would be the ones with +.

As written above I'm not sure this is worth investigating and fixing, but just wanted to report as it gave me by chance some worries while rebuilding and retesting the new version of Robotframework. I will just redo the tests tomorrow ;-)

Version Information:
Tried with both 6.0 and 5.0.1

Steps to reproduce:
Run the unit tests, specifically on the day immediately before or after DST change.

Error message and traceback:

======================================================================
FAIL: test_parse_time_with_now_and_utc (test_robottime.TestTime)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/foo/rpmbuild/BUILD/robotframework-6.0/utest/utils/test_robottime.py", line 341, in test_parse_time_with_now_and_utc
    assert_true(expected <= parsed <= expected + 1),
  File "/home/foo/rpmbuild/BUILD/robotframework-6.0/utest/../src/robot/utils/asserts.py", line 115, in assert_true
    _report_failure(msg)
  File "/home/foo/rpmbuild/BUILD/robotframework-6.0/utest/../src/robot/utils/asserts.py", line 218, in _report_failure
    raise AssertionError()
AssertionError

----------------------------------------------------------------------

[pekkaklarck]

Thanks for the report. It seems the code takes possible DST change correctly into account. Based on the version control history the code was enhanced last January in eb82172 to fix #4143. Need to enhance this unit test to take possible DST transition into account. Not too hard but god I hate DST.