What should we do about this?
Details
Diff Detail
- Repository
- rDSTO Storage manager
- Branch
- weird-git
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 25551 Build 39946: Phabricator diff pipeline on jenkins Jenkins console · Jenkins Build 39945: arc lint + arc unit
Event Timeline
Build has FAILED
Patch application report for D6819 (id=24698)
Could not rebase; Attempt merge onto 7cb4128e40...
Updating 7cb4128e..5d7b43ab Fast-forward swh/storage/postgresql/converters.py | 5 +- swh/storage/tests/storage_data.py | 26 ++++ swh/storage/tests/storage_tests.py | 17 +++ swh/storage/tests/test_postgresql.py | 7 + swh/storage/tests/test_postgresql_converters.py | 187 +++++++++++++++++------- 5 files changed, 190 insertions(+), 52 deletions(-)
Changes applied before test
commit 5d7b43abfd0fe7dd4876102218af2f0f8731d335 Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 17:04:40 2021 +0100 Add test_revision_add_old, xfail on postgresql commit 110e2c3cbd6fca00a0e8cce5e43cf81c7fd216cc Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 16:25:20 2021 +0100 postgresql: Fix one-by-one error in db_to_date on negative dates Using `int()` on `date.timestamp()` rounded it up (toward zero), but the semantics of `model.Timestamp` is that the actual time is `ts.seconds + ts.microseconds/1000000`, so all negative dates were shifted one second up. In particular, this causes dates from `1969-12-31T23:59:59.000001` to `1969-12-31T23:59:59.999999` (inclusive) to smash into dates from `1970-01-01T00:00:00.000001` to `1970-01-01T00:00:00.999999`, which is how I discovered the issue. commit 34ca67e21f68de920f603223f629070683018c2a Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 16:23:44 2021 +0100 postgresql: Add tests for db_to_date.
Link to build: https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1499/
See console output for more information: https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1499/console
Build has FAILED
Patch application report for D6819 (id=24699)
Could not rebase; Attempt merge onto 7cb4128e40...
Updating 7cb4128e..0bdc7e8b Fast-forward swh/storage/postgresql/converters.py | 5 +- swh/storage/tests/storage_data.py | 24 +++ swh/storage/tests/storage_tests.py | 17 +++ swh/storage/tests/test_postgresql.py | 7 + swh/storage/tests/test_postgresql_converters.py | 187 +++++++++++++++++------- 5 files changed, 188 insertions(+), 52 deletions(-)
Changes applied before test
commit 0bdc7e8b9e11ed42396740c8f915d9a01a5de53e Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 17:04:40 2021 +0100 Add test_revision_add_old, xfail on postgresql commit 110e2c3cbd6fca00a0e8cce5e43cf81c7fd216cc Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 16:25:20 2021 +0100 postgresql: Fix one-by-one error in db_to_date on negative dates Using `int()` on `date.timestamp()` rounded it up (toward zero), but the semantics of `model.Timestamp` is that the actual time is `ts.seconds + ts.microseconds/1000000`, so all negative dates were shifted one second up. In particular, this causes dates from `1969-12-31T23:59:59.000001` to `1969-12-31T23:59:59.999999` (inclusive) to smash into dates from `1970-01-01T00:00:00.000001` to `1970-01-01T00:00:00.999999`, which is how I discovered the issue. commit 34ca67e21f68de920f603223f629070683018c2a Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 16:23:44 2021 +0100 postgresql: Add tests for db_to_date.
Link to build: https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1500/
See console output for more information: https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1500/console
Build is green
Patch application report for D6819 (id=24700)
Could not rebase; Attempt merge onto 7cb4128e40...
Updating 7cb4128e..7765309a Fast-forward swh/storage/postgresql/converters.py | 5 +- swh/storage/tests/storage_data.py | 23 +++ swh/storage/tests/storage_tests.py | 17 +++ swh/storage/tests/test_postgresql.py | 7 + swh/storage/tests/test_postgresql_converters.py | 187 +++++++++++++++++------- 5 files changed, 187 insertions(+), 52 deletions(-)
Changes applied before test
commit 7765309a7e3b8a2d2e8f59fd434849fe247e28a3 Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 17:04:40 2021 +0100 Add test_revision_add_old, xfail on postgresql commit 110e2c3cbd6fca00a0e8cce5e43cf81c7fd216cc Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 16:25:20 2021 +0100 postgresql: Fix one-by-one error in db_to_date on negative dates Using `int()` on `date.timestamp()` rounded it up (toward zero), but the semantics of `model.Timestamp` is that the actual time is `ts.seconds + ts.microseconds/1000000`, so all negative dates were shifted one second up. In particular, this causes dates from `1969-12-31T23:59:59.000001` to `1969-12-31T23:59:59.999999` (inclusive) to smash into dates from `1970-01-01T00:00:00.000001` to `1970-01-01T00:00:00.999999`, which is how I discovered the issue. commit 34ca67e21f68de920f603223f629070683018c2a Author: Valentin Lorentz <vlorentz@softwareheritage.org> Date: Thu Dec 9 16:23:44 2021 +0100 postgresql: Add tests for db_to_date.
See https://jenkins.softwareheritage.org/job/DSTO/job/tests-on-diff/1501/ for more details.
Can you get a cite for the "loss of precision" on very old timestamps? timestamp with time zone is supposed to have a microsecond of precision in its whole range of operation, which goes from year -4713 to year 294276.
Actually, it was a "bug" of psycopg2 < 2.9.0 with non-integer timezones: https://www.psycopg.org/docs/usage.html#time-zones-handling
I'll submit a new diff to bump the psycopg2 dependency and remove the xfail