tests fail in year 2038

[bmwiedemann]

While working on reproducible builds for openSUSE I found that
our python-exiv2 fails 2 tests (on x86_64) when run after the 0x7fffffff 31-bit overflow of the signed UNIX epoch (count of seconds since 1970)

======================================================================
FAIL: test_DateValue (test_value.TestValueModule)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/python-exiv2-0.17.1/tests/test_value.py", line 378, in test_DateValue
    self.do_conversion_tests(value, py_date.isoformat(), seconds)
  File "/home/abuild/rpmbuild/BUILD/python-exiv2-0.17.1/tests/test_value.py", line 94, in do_conversion_tests
    self.assertAlmostEqual(
AssertionError: -2147408896.0 != 2147558400.0 within 5 places (4294967296.0 difference)

======================================================================
FAIL: test_TimeValue (test_value.TestValueModule)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/abuild/rpmbuild/BUILD/python-exiv2-0.17.1/tests/test_value.py", line 448, in test_TimeValue
    self.do_conversion_tests(value, py_time.isoformat(), seconds)
  File "/home/abuild/rpmbuild/BUILD/python-exiv2-0.17.1/tests/test_value.py", line 79, in do_conversion_tests
    self.assertAlmostEqual(result, float(number), places=5)
AssertionError: 81252.0 != -5148.0 within 5 places (86400.0 difference)

----------------------------------------------------------------------
Ran 59 tests in 0.031s

FAILED (failures=2, skipped=2)

In Debian and openSUSE, you can reproduce it with

osc checkout openSUSE:Factory/python-exiv2 && cd $_
osc build --vm-type=kvm --noservice --clean --build-opt=--vm-custom-opt="-rtc base=2038-01-20T00:00:00" -j4 standard

And maybe using faketime can also trigger the issue.

[jim-easterbrook]

Thanks for that. Do you know if other applications using libexiv2 suffer a similar problem? I'm assuming it's a problem in libexiv2 itself, but I'll investigate further next week.

[bmwiedemann]

I did not see any others so far... but OTOH most projects don't run as many automated tests as python does.

[jim-easterbrook]

I've found the problem with test_DateValue. It's checking the result of DateValue.toRational, which is of type Exiv2.Rational.
https://exiv2.org/doc/classExiv2_1_1DateValue.html#a9897cf9cee63d3f4d073db3c2d0ad355

Exiv2.Rational is defined as a pair of int32_t.
https://exiv2.org/doc/namespaceExiv2.html#a03e01c8ca5f7a70f166db6b05115bef7

For most sensible uses of Exiv2.Rational this is quite sufficient, so I don't expect the exiv2 project would welcome any attempt to change it. There is no sensible reason to want a UNIX timestamp as a rational number, so I may just remove this from the Python interface.

The problem with test_TimeValue is similar.
https://exiv2.org/doc/classExiv2_1_1TimeValue.html#a3f35dfcf48c850030e57e960e32085ea

[jim-easterbrook]

I've just realised that the problem with test_TimeValue is completely unrelated. I'm including a time zone in my test TimeValue and have never run the test at a time when the time zone offset could make the result negative. libexiv2 offsets negative results by 1 day, but my Python test module doesn't, which gets picked up by running the tests at 2038-01-20T00:00:00 - ie. midnight!

[jim-easterbrook]

I've released version 0.17.2 which includes the bug fix for TimeValue tests. The "binary wheels" on PyPI include libexiv2 v0.28.4 which includes a fix for the integer overflow error in DateValue (Exiv2/exiv2#3081).