Issue421 improvements for specifying temporal extent with single string

[JohanKJSchreurs]

More improvements for issue #421

Follow up after PR #461

Overview of Changes

• Made most functions internal, because they were indeed not actually intended to be user facing.
• Documented the use of temporal extent with and without the shorthand notation for years and months in the page for data_access.html, and referring to in the getting started page.
• Added test coverage via Connection.load_collection, DataCube.filter_temporal.
• Usage like cube.filter_temporal("2020", "2022") or load_collection(..., temporal_extent=["2021-03", "2022-04"]) made sense so that is supported now as well.
• In fact the simplest way to specify a year, for example temporal_extent="2023" wasn't actually supported, still had to use a tuple. So corrected that.
• Update CHANGELOG so feature is mentioned.
• Finally, moved the temporal extent functions to a separate module (split up openeo.util #465)

[JohanKJSchreurs]

Closed accidentally, I hit the wrong button or something. So I reopened it.

[soxofaan]

FYI: I pushed a commit on this feature branch to further finetune the docs (improve hierarchy a bit, moved some things around and tried to make some things more compact).

Doing it a commit seemed easier than trying to explain it as PR review :)

[soxofaan]

While reading the new docs and going through the tests, I'm starting to think that my suggestion from #421 (comment)

is usage like cube.filter_temporal("2020", "2022") or load_collection(..., temporal_extent=["2021-03", "2022-04"]) also handled: take first day of start date and last day + 1 for end date

was a bad idea. As you note in the docs and code comments, the behavior is now inconsistent and confusing I think:

• normalize_extent("2019-03-15", "2019-10-11") would be handled left-closed -> [2019-03-15, 2019-10-11[
• normalize_extent("2019-03", "2019-04") would be handled fully inclusive -> [2019-03-01, 2019-05-01[ instead of [2019-03-01, 2019-04-01[

I think we should work "left-closed" style everywhere.

As I'm knee-deep in the code already, I'm going to give it a go: starting with updating/extending the tests to make the outcomes more consistent, and then seeing if I can fix the implementation as well

[JohanKJSchreurs]

While reading the new docs and going through the tests, I'm starting to think that my suggestion from #421 (comment)

is usage like cube.filter_temporal("2020", "2022") or load_collection(..., temporal_extent=["2021-03", "2022-04"]) also handled: take first day of start date and last day + 1 for end date

was a bad idea. As you note in the docs and code comments, the behavior is now inconsistent and confusing I think:

* `normalize_extent("2019-03-15", "2019-10-11")` would be handled left-closed -> `[2019-03-15, 2019-10-11[`

* `normalize_extent("2019-03", "2019-04")` would be handled fully inclusive -> `[2019-03-01, 2019-05-01[` instead of `[2019-03-01, 2019-04-01[`

I think we should work "left-closed" style everywhere.

As I'm knee-deep in the code already, I'm going to give it a go: starting with updating/extending the tests to make the outcomes more consistent, and then seeing if I can fix the implementation as well

Much better indeed. With your improvements, I find the usage a lot easier to understand.
Looks good to me.

[soxofaan]

ok thanks for the review,
I'll rebase and merge

[soxofaan]

rebased and merged in b734ea8