Implement the time bounding query

[jkerr5]

Handle the time query parameter to limit the time instant or the time extent to query.

See: https://developers.arcgis.com/rest/services-reference/query-feature-service-layer-.htm

[jkerr5]

We will need something in the feature service descriptor to tell the service what column or range index to use for the time range queries.

If we use a range index, it needs to go in the bounding CTS query and the rows that are returned will only be from documents that match the given time range.

If we use a date/time column from the row, it needs the date range query term needs to be added to the optic where query.

We probably want to support both ways of specifying what field/index to use.

We also need to look at how this plays with the timeInfo part of the layer resource as described here https://developers.arcgis.com/rest/services-reference/layer-feature-service-.htm This is the relevant section:

   "timeInfo" : {
     "startTimeField" : "<startTimeFieldName>",
     "endTimeField" : "<endTimeFieldName>",
     "trackIdField" : "<trackIdFieldName>",
     "timeExtent" : [<startTime>, <endTime>],
     "timeReference" : {
       "timeZone" : "<timeZone>",
       "respectsDaylightSaving" : <true | false>
     },
     "timeInterval" : <timeInterval>,
     "timeIntervalUnits" : "<timeIntervalUnits>"
   },

I don't know if koop supports generating this and/or if this affects the how the feature service clients use the time query parameter.

[jkerr5]

@jmamanpara, looking at the koop code, it looks like they will pass through timeInfo metadata that comes from the provider.

Try including timeInfo in the layer metadata in the generateServiceDescriptor() function of the provider.

[gduplantier]

I have a basic capability working for my project. I can expand this and submit a pull request. Currently I only support the row data/optic query. I can look into adding to the bounding query as well. I also assume documents are in UTC time. I'll need to add code that looks at the timeReference section and converts to the properly configured TZ offset. Will also need to do some date math for date ranges (start/end time, as opposed to just a start time)

[jkerr5]

This is covered in GDS already.