Description
As per Temporal Extent Object description: https://github.com/radiantearth/stac-spec/blob/v1.0.0/collection-spec/collection-spec.md#temporal-extent-object , interval has type [[string|null]] ; however in the same chapter [Temporal Extent Object] is stated :
"Each inner array consists of exactly two elements, either a timestamp or null. "
"Timestamps consist of a date and time in UTC and MUST be formatted according to RFC 3339, section 5.6. "
So, the strings that compose this interval should be as per RFC 3339, but no constraint for this is actually implemented, any string is accepted as good at this moment.
If we look at class TimeInterval(StacBaseModel) ,
stac-pydantic/stac_pydantic/collection.py
Line 22 in 0b5a8a2
in contrast with:
https://github.com/stac-utils/stac-pydantic/blob/0b5a8a299e8175621e7b656dd1e5deba0cc7d9de/stac_pydantic/shared.py#L28C1-L28C12 , that for an item datetime is a "string" too but it has a validator.
we think that a validator is also needed for TimeInterval ,
stac-pydantic/stac_pydantic/collection.py
Line 22 in 0b5a8a2
The issue described here is causing a problem when the collection schema https://github.com/radiantearth/stac-spec/blob/v1.0.0/collection-spec/collection-spec.md is used to automatically generate an example value ( https://github.com/radiantearth/stac-spec/blob/v1.0.0/collection-spec/collection-spec.md#extent-object is used for the extent ) , thus generating "string" as value instead of an actual valid date-time for the extent -> temporal -> interval . This causes an error if the example is used as is for example in
https://github.com/stac-utils/stac-fastapi-pgstac/blob/42cea5d22ac5dc3b77d394f12ce2212ad6538a87/stac_fastapi/pgstac/transactions.py#L152C13-L152C64 ( File "asyncpg/protocol/protocol.pyx", line 206, in bind_execute
asyncpg.exceptions.InvalidDatetimeFormatError: invalid input syntax for type timestamp with time zone: "string")