-
Notifications
You must be signed in to change notification settings - Fork 204
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test failures after 2038 #431
Comments
Yes this is a known issue.It is a combination between these numbers being strongly time-bound (what is considered a valid number today might not be 10 years from now because the laws may have changed) combined with some ambiguity in their definition (we try to reconstruct a birth date but because for years often only 2 digits are stored we could be 100 years off) means that some tests are time-bound. |
Could the tests be updated to state some truths that remain true? |
Your best bet is probably to run the tests with a fixed date/time by mocking the system time. I want to avoid that in the development branch because that means we will likely miss these kind of changes. If there is a way this can be made easier in python-stdnum (e.g. some environment variable that ensures the time is set to a particular date or something), please let me know. Even better would be to provide a fix 😉 because I sadly only have very limited time at the moment. |
While working on reproducible builds for openSUSE, I found that our
python-stdnum-1.20
package sometimes fails its tests and it might be related to the date the tests are run.The observed bad build-start dates (in UTC) so far were
2038-04-12T03:26:46
2039-10-18T00:10:26
2040-04-24T18:41:17
test output was
The text was updated successfully, but these errors were encountered: