date-time type parameters accept UTC timestamps only

[komima]

Using datetime (or a custom attribute parameter with for example DatetimeRangeMapper) does not accept other than UTC timestamp values as input.

• ?datetime=2020-01-01T00:00:00Z works
• ?datetime=2020-01-01T02:00:00+02:00 fails with 'datetime' value could not be parsed

OAPIF spec says RFC 3339, 5.6, which allows offsets.

[jampukka]

Shouldn't be big or problematic change. Adjust the parameter handlers and mappers to accept values with offsets but handle everything in UTC inside hakunapi.

Somehow I'm thinking Core 1.0 was only supposed to support UTC timestamps, but I can't find anything that would say so.

[jratike80]

Maybe it is this ticket opengeospatial/ogcapi-features#483

[teezip]

Talked about this on Hakunapi development meeting: to better comply with standard (fix on UTC timestamps) and avoid comparison issues (between timezones) also Hakunapi should only allow UTC timestamps.

So considering rejecting this. Or is there some particular use case where timestamps with offsets would be required?

[teezip]

Reading comments above and standard spec again..

As @komima originally commented the standard OGC API - Features - Part 1: Core allows also timestamps with offsets as it's specified only by this clause:

Parameter datetime: The syntax of date-time is specified by
RFC 3339, 5.6

Also OGC API - Common - Part 2: Geospatial Data DRAFT (https://docs.ogc.org/DRAFTS/20-024.html) specifies the same.

Restricting timestamp to UTC maybe (?) related to CQL queries as noted above?

So according to OGC API Features : Core 1 and commons part 2 draft this seem to be a bug in Hakunapi (even if it would be more explicit using just those UTC timestamps), but maybe fixing this is not priority 1 if there are not specific use cases for using timestamps other than UTC in datetime parameter?

[jratike80]

Yes, it is written into the OGC API Common that the syntax of date-time is specified by RFC 3339 and so there is a bug in Hakunapi
. That leads into a strange situation: it should be possible to use datetime with the timezone in query, but for making the same query with CQL2 the time must be converted into UTC. I would say that it least it would be a best practice to stay with UTC all the time.

[jratike80]

This is now clarified in opengeospatial/ogcapi-common#342.

OGC API Features server must accept also timestamps with local time offsets
?datetime=2020-01-01T02:00:00+02:00

A separate thing is that in filter local time offsets cannot be used because the CQL2 standard supports only UTC times.