temporal: add unit tests for AbstractSpaceTimeDataset shift() and snap()

[selma-Bentaiba]

Summary

Adds missing test coverage for shift() and snap() methods of
AbstractSpaceTimeDataset, which had no dedicated unit tests.

Tests added

• test_shift_absolute_time: timestamps advance by the given granularity
• test_shift_invalid_granularity: regression test for temporal: fix string formatting in fatal error messages #7228, ensures
  invalid input returns False rather than a formatting TypeError
• test_snap_closes_gaps: end times are snapped to next map's start time

Notes

test_shift_relative_time is commented out. Relative time unit type
resolution fails in GRASS 7.8.7 with 'unsupported unit type: None'.
Needs verification against GRASS 8.x once #7231 is merged.

Related

#7228 #7231

[echoix]

How did you even get 7.8.7 working? Yes it is a release, but hidden multiple pages after in the releases, like 11 releases behind.

[ninsbl]

Please install and use pre-commit hooks in your dev setup.

[echoix]

You know you could just run uvx prek or uvx prek -a to run most basic formatting and linting checks, without installing anything (except uv) before using up an hour of limited and shared CI time?

[selma-Bentaiba]

How did you even get 7.8.7 working? Yes it is a release, but hidden multiple pages after in the releases, like 11 releases behind.

Haha, you definitely caught me there! I just ran a standard sudo apt install grass on my Ubuntu machine,
and I didn't realize quite how far back the official repo was until you mentioned the 11-release gap.

As you can see from the distutils warnings in the screenshot, Python 3.10 is definitely screaming at Version 7! I actually moved forward with the initial PR because the core TGIS logic I was studying seemed consistent across the versions, but I completely see why that architectural gap is a major issue for a modern contribution.

I’ve already purged the legacy version and am currently moving to the 8.4 dev branch (via the UbuntuGIS PPA) to ensure the PR and my propo
sal are built on a modern, stable architecture. Thanks for the catch!

[selma-Bentaiba]

Please install and use pre-commit hooks in your dev setup.

Message received.
I’ve officially installed and configured the pre-commit hooks in my local dev setup. I’m moving toward a 'local-first' validation workflow to ensure my contributions meet the project's engineering standards before I push.
Appreciate the guidance on the professional workflow.

[selma-Bentaiba]

You know you could just run uvx prek or uvx prek -a to run most basic formatting and linting checks, without installing anything (except uv) before using up an hour of limited and shared CI time?

To be honest, I have uv installed, but I’ve been too focused on the TGIS logic and mistakenly relied on the CI for the formatting checks. I definitely see now how that impacts project resources.

I’ve officially integrated uvx prek and the pre-commit hooks into my local save-flow so I don't waste any more shared CI time on linting. Lesson learned ++

[echoix]

7.8.7 from a distro’s repo makes sense, sorry about my tone. It’s because of the years, it coincides with what many LLMs were trained on, and there’s no way a contributor making efforts would choose that to test on.

Even 8.4 is quite old. 8.5 (not out yet, but should be soon), has more than 1.5 years of improvements, especially in code quality. Theres not that much in 8.4, but way more in 8.5. In the years before, code quality wasn’t as of a priority as it is now. So python errors in 7.8.7 mean nothing now

[selma-Bentaiba]

After further local testing and refactoring, I have updated this PR to meet the latest standards:

• 8.4.2 Structure: Verified that tests are correctly placed and formatted for the current release.

• Refactored Code: All pytest-style assertions and linting (via ruff) are now integrated.

• Local Integration Test: I launched a full GRASS 8.4.2 session and successfully ran the tests against a fresh temporal database (world_latlong_wgs84/PERMANENT).

• Result: Ran 3 tests... OK. (See attached screenshot for the local execution log).

Ready for final review. @ninsbl @echoix Thank you for the guidance on setting up the environment!

[selma-Bentaiba]

7.8.7 from a distro’s repo makes sense, sorry about my tone. It’s because of the years, it coincides with what many LLMs were trained on, and there’s no way a contributor making efforts would choose that to test on.

Even 8.4 is quite old. 8.5 (not out yet, but should be soon), has more than 1.5 years of improvements, especially in code quality. Theres not that much in 8.4, but way more in 8.5. In the years before, code quality wasn’t as of a priority as it is now. So python errors in 7.8.7 mean nothing now

I appreciate the explanation @echoix !
I totally get it .. it was a bit of a battle to outrun my distro’s 7.8.7 defaults, but I’ve finally got 8.4.2 stabilized locally. The PR is all modernized now and ready for the upcoming steps. Glad we're on the same page ^^

[ninsbl]

Sorry for not checking earlier, did you see the t.shift tool tests: https://github.com/OSGeo/grass/blob/main/temporal/t.shift/testsuite/test_shift.py ? What do these unittests add?

[selma-Bentaiba]

Sorry for not checking earlier, did you see the t.shift tool tests: https://github.com/OSGeo/grass/blob/main/temporal/t.shift/testsuite/test_shift.py ? What do these unittests add?

After digging into the existing t.shift and t.snap suites, I’ll admit my approach was a bit redundant; I’m still learning the layers ...

That said, I found a few gaps where this PR may actually pulls its weight:

• Direct Testing: CLI tests check the 'wrapper,' but my tests hit the Python methods directly.

• Plugging Holes: TestShiftAbsoluteError in the current suite is currently empty; test_shift_invalid_granularity finally gives it something to do.

• Precision: Existing tests check if a timestamp changes, but mine actually verify the exact datetime values.

I’m happy to keep this as a new file or just migrate these 'gap-fillers' into the existing suites to keep things lean. What’s the cleaner move?" @ninsbl

[echoix]

If there’s a test file per Python class, usually that’s good. If the tests could benefit from the same setup/teardown as the existing file -> keep in the same file. If your test setup/teardown is simpler (and faster to run) -> maybe a different file?

temporal tests are way longer than they should be, probably something in the library, but either way, temporal tests take the same time as all the rest, combined.

[selma-Bentaiba]

@echoix Thank you for your notes, it helps a bunch .
I have updated the PR to address all feedback:

• Licensing: Added the SPDX-License-Identifier header.
• Test Discovery: Renamed the file to test_temporal_stds_management.py. It is now correctly discovered by the pytest runner.
• Code Maintenance: Removed all commented-out code and legacy TODOs for a cleaner codebase.
• Verification: Verified locally that all 3 tests pass (OK) using grass --exec pytest on GRASS 8.4.

Additionally, I've run the pre-commit hooks to ensure the file meets all project formatting standards (Ruff/formatting)

[echoix]

For your warning, install pytest-timeout package. It is partly for temporal tests taking way too long that we limited the time taken, but temporal tests usually run through gunittest.

But if your test can run through pytest, it could be great to whitelist that gunittest file to be ran with pytest (in .github/workflows/pytest**.txt files), and blacklist it in .gunittest.cfg).

It would need to pass CI on all our platforms, but it would be great!

[petrasovaa]

I used AI to rewrite this to pytest, dropped the test that duplicated t.shift/testsuite/test_shift.py, and strengthened the snap test.

[echoix]

Let’s go with this