Update datetime filter

[jonhealy1]

Related Issue(s):

• Datetime filter #391
• Allow datetime filtering options #403

Description:

• Improved datetime query handling to only check start and end datetime values when datetime is None

PR Checklist:

• Code is formatted and linted (run pre-commit run --all-files)
• Tests pass (run make test)
• Documentation has been updated to reflect changes, if applicable
• Changes are added to the changelog

[rhysrevans3]

Is this enough to give all possible combinations of datetime overlap? This looks like it will only return items whose date range entirely encapsulates the searched for date range.

[jonhealy1]

This test case shows overlap.

# Test 5: Range matching null-datetime-item but not range-item's datetime
    feature_ids = await _search_and_get_ids(
        app_client,
        params={
            "datetime": "2020-01-01T12:00:00Z/2020-01-02T12:00:00Z",
            "collections": [collection_id],
        },
    )
    assert feature_ids == {
        "null-datetime-item",  # Overlaps: search range [12:00-01-01 to 12:00-02-01] overlaps item range [00:00-01-01 to 00:00-02-01]
    }, "Range search excluding range-item datetime failed"

[rhysrevans3]

If I'm reading the test correctly the null-datetime-item items has a date range of 2020-01-01T00:00:00Z to 2020-01-02T00:00:00Z and the search is 2020-01-01T12:00:00Z/2020-01-02T12:00:00Z so the searched date range it entirely within the item's date range. If the searched for range's end date was extended by a day so was 2020-01-01T12:00:00Z/2020-01-03T12:00:00Z I suspect the item wouldn't be returned. Is that the desired behaviour? I thought that if there was any overlap then the item should be returned.

[jonhealy1]

I might be mixed up, but the item has a 24hr. date range and so does the query so they do overlap?

[jonhealy1]

The end date of the search is outside the items end date

[rhysrevans3]

Sorry yes you're 100% right! I didn't realise datetime_search["lte"] was the end date of the search and datetime_search["gte"] was the start. This is a really neat way of doing this search!

[jonhealy1]

It is pretty neat

[rhysrevans3]

Same as below.

[rhysrevans3]

The current best practices recommends that you populate datetime even if you have a date range.

"The specification does allow one to set the datetime field to null, but it is strongly recommended to populate the single datetime field, as that is what many clients will search on. If it is at all possible to pick a nominal or representative datetime then that should be used."

So we should probably loosen the search (remove this line?) or update the recommended practice.

[jonhealy1]

I don't know. I think the best practices are recommended but may not always be relevant for all types of data.

[jonhealy1]

@rhysrevans3 Can you look at this issue #396? I am not 100% sure on what the right approach should be.

[jonhealy1]

I think that for some items, defined by start and end datetimes, it may not make sense to set a datetime value just for the sake of doing so. The stac spec itself allows null datetime values.

[rhysrevans3]

I think you're right both the case for a null or set datetime when start and end dates are used needs to be handled. What's the expected behaviour when the datetime is set? I would expect it to search on all date fields. If that's the case then I think the must_not=[Q("exists", field="properties.datetime")] can be removed. I think the current query will ignore start and end dates if the datetime is set. Is that expected?

[jonhealy1]

Are you thinking of documenting this in the readme or maybe something else?

[jonhealy1]

We could have a few options; default - this one maybe, start and end datetimes included, only datetime

[rhysrevans3]

I was more thinking of a way to tell the user doing the search which behaviour to expect. But I can't think of a good place to put it, other than the queryables endpoint maybe? But including it in the readme is probably enough.

[jonhealy1]

I'll open an issue for this so we can work on it later. We can definitely use logging too.

[jonhealy1]

#403