date-time type parameters accept UTC timestamps only

[komima]

date-time type parameters accept UTC timestamps only

[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.