Closed jcfp closed 4 years ago
Thanks for the report. In c4b4528, I've attempted to replicate the error by setting the timezone as you described. Interestingly, I get failures when the current time is 12:01 or 13:01 UTC, but weirdly, I don't get the error you describe. Instead, the test fails sooner on the assertion of cmd.due() is False
, so I seem to have found a (related) issue, but not precisely the one you've reported. Here's the output of the tests:
Do you have any idea why I've failed to replicate your findings?
What's more disconcerting is that in reviewing the code, I'd expect everything to be handled in UTC, (including the command execution time), so I'd expect it not to be influenced by the local timezone, though it is apparent it is affected, so more investigation is needed.
Oh, one more thing - when I download those log files, they appear to be binary. They open as binary in SublimeText and as gibberish text in TextEdit. Do you have any advice on how to download or view those files?
tempora bugfix/8-distant-timezone $ with open('/Users/jaraco/Dropbox/Downloads/python-tempora_1.14.1-2.rbuild.log', 'rb') as strm:
................................... strm.readline()
...................................
b'\x1f\x8b\x08\x00\x00\x00\x00\x00\x02\x03\xb4[\xe9n\xe3H\x92\xfeO\xa0\xdf!g\xb0\x83\xaa\x82\x8b\x14\x937\xb5\xdd\x8d\x96|\xc8\x97l\x97o\xbb\xd0(PdJ\xa2\xc5\xcb<t\r\x06\x98\xc7\xd8}\xbdy\x92\x8d\xe4\xa5\x94,\xb9\xaaZZ\x15\xcaV\x9e_Fd\xe4\x17\x11I\xfa&\x0b\xd0\x01\xb1\x112\x10\xc6MIi\x8a:\xba\xbb\xddG\x92\x88M\x84N\x9a(I\xad8u\x83\x01JC\xd4\xcb\\\xcfA\xd1,\x1d\x86\x01\x9f\x12?\n'
It seems the attached files have been gzipped. Rename the extension to gz and any archiver should be able to handle.
No clue why another assert is triggered in your attempt at replicating the bug, upon noticing the issue I more or less assumed any timezone with a difference of more than 12 hours from UTC would do the job.
No clue why another assert is triggered in your attempt at replicating the bug, upon noticing the issue I more or less assumed any timezone with a difference of more than 12 hours from UTC would do the job.
I figured it out. I was testing against UTC-14, but your failed test was UTC+14. When I test against UTC+14, I trigger the same failure.
hi, a recent build of tempora in debian reproducibility testing failed. Reproducibility testing aims to ensure rebuilds of packages are bit by bit identical by doing two builds, introducing variations in paths, language settings, time/timezones and so on.
In a build with the timezone set to UTC+14, 'test_command_at_noon' failed:
I suspect the above may be triggered by the combination of the timezone used and the time just before noon UTC. The other build, which had the time set to January 2021 with tz UTC-12, worked fine.
Full build logs attached, the failure is in "build2". python-tempora_1.14.1-2.build2.log python-tempora_1.14.1-2.rbuild.log