MDEV-38874: Make tests pass after 2030#4667
Conversation
|
|
bmwiedemann
force-pushed
the
ftbfs2030
branch
from
84aa7c8 to
b4493ad
Compare
gkodinov
added
the
External Contribution
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for your contribution. This is a preliminary review.
This sounds like a test case bug fix. As such, it needs to go to the lowest affected version, which currently is 10.6. Can you please re-base your changes to that?
If you would also please document why you went with 2080 instead of 2030.
Why not year 4k for example?
|
I don't think 10.6 can handle timestamps larger than 2038. MDEV-32188 was implemented in 11.5, so the first capable version now is 11.8 And even 11.8 cannot handle years larger than 2106. |
bmwiedemann
force-pushed
the
ftbfs2030
branch
2 times, most recently
from
6c758c4 to
3806b9b
Compare
|
I added 3 lines of explanation to the commit message and rebased it onto 11.8 |
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
Thank you for updating the commit message.
VERSION
Outdated
| @@ -1,4 +1,4 @@ | |||
| MYSQL_VERSION_MAJOR=13 | |||
| MYSQL_VERSION_MINOR=0 | |||
| MYSQL_VERSION_PATCH=0 | |||
There was a problem hiding this comment.
Why do you need to bump the version?
This is not relevant to the fix. Please revert that.
2080 was chosen because it is far enough into the future to not have to worry, but still below 2106 which is the new limit after implementation of https://jira.mariadb.org/browse/MDEV-32188 Background: As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future. I tested with an offset of +11 years, because that is how long I expect some software will be used in some places. This showed up failing tests in our mariadb package build. See https://reproducible-builds.org/ for why this matters.
bmwiedemann
force-pushed
the
ftbfs2030
branch
from
3806b9b to
7b602db
Compare
|
The version bump was some unintended artifact from the rebase - I dropped that now. Another consideration is that this change will break those 3 tests on systems with 32-bit One way out could be to replace the date with "now + 5 years" (not sure how that works in SQL and that test-framework) so that it keeps working indefinitely for 64-bit time_t and until 2033 for 32-bit time_t |
gkodinov
left a comment
gkodinov
left a comment
There was a problem hiding this comment.
LGTM now. Please stand by for the final review.
On the older systems: maybe exclude these tests that you expect to fail?
|
hmm, the PR is still against MariaDB::main? Are you sure you've rebased it? |
|
Is |
4 participants
Background:
As part of my work on reproducible builds for openSUSE, I check that software still gives identical build results in the future. I tested with an offset of +11 years, because that is how long I expect some software will be used in some places. This showed up failing tests in our mariadb package build. See https://reproducible-builds.org/ for why this matters.