I'm seeing some odd failures in python setup.py test that go away when I set the TZ environment variable.
python setup.py test
TZ
With no TZ env var set:
$ python setup.py test [... snip ...] ====================================================================== FAIL: test_create_next_test_compose_dir (tests.test_create_next_dir.CreateNextDirTest) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/kdreyer/dev/compose-utils/svenv/lib/python2.7/site-packages/freezegun/api.py", line 495, in wrapper result = func(*args, **kwargs) File "/home/kdreyer/dev/compose-utils/tests/test_create_next_dir.py", line 91, in test_create_next_test_compose_dir self.assertEqual(out.getvalue().strip(), compose_dir) AssertionError: '/tmp/tmpavW9s2/_compose_K1TpWj/DP-1.0-20151231.t.0' != '/tmp/tmpavW9s2/_compose_K1TpWj/DP-1.0-20160101.t.0'
... and I get several more test failures like this, where "December 31st 2015" does not match with "January 1st 2016"
When I set TZ to anything, the tests all pass.
TZ=1 python setup.py test
This is interesting. I don't have TZ set in my environment and the tests are passing. I have not seen this failure in Jenkins, COPR or during Koji build either.
In what locale are you seeing this? What version of python-freezegun?
I dug a little more on this and the problem seems to be related to /etc/localtime.
When I fire up a rawhide container and /etc/localtime points at UTC, then all is well.
When I change the container's /etc/localtime's symlink to point to my timezone (/usr/share/zoneinfo/America/Denver), the tests fail in this way.
Ah, that's it. I had a CEST timezone, but once I switch to Denver I get the failures as well. The problem seems that in tests we freeze the time with the python-freezegun library, but for time.localtime() call the system timezone is still used. Using datetime instead we should get the same results but with working tests: #51.
time.localtime()
datetime
Metadata Update from @lsedlar: - Issue assigned to lsedlar
Metadata Update from @lsedlar: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.