time property considerations

[tomkralidis]

Following discussion in opengeospatial/ogcapi-records#168, for cconsideration?

Changing time to datetime

• datetime is a parameter from OGC API Common
• many OGC APIs already support the datetime parameter, per RFC3339
• JSON Schema delineates date, time, date-time, for example
  • so do many programming languages
• time COULD result in confusion (emitting JUST the time with no date?)

Adding resolution

• related to consider temporal resolution ogcapi-records#147, can a resolution property be added (to express the notion of, say, hourly data, etc.)

[tomkralidis]

Examples:

  "datetime": {
    "timestamp": "2021-10-30"
  }

  "datetime": {
    "interval": ["2021-01-01", "2021-12-31"],
    "resolution": "P1D"
  }

[cportele]

Meeting 2022-07-11:

• time -> datetime: We understand where this comes from, but the reason for using "time" was to use a general term that is understood as "temporal information". "datetime" can be misleading (if you get a date) as can be "time" (if one is surprised to get a date). In general we tend to stick to "time", because of it being the more general term.
• resolution: Currently it is only used in an example in Records? It would be good to understand first how it is defined and how/why this is useful in data. @tomkralidis - can you provide more information? Maybe it would make sense to discuss it in Records first and then see, what we do in JSON-FG?

[cportele]

OGC Code Sprint 2022-09-15:

• when would have be an intuitive and not-technical name for the member, but we want to avoid the name conflict. For now, time seems to be better than datetime for the reasons mentioned above, but we will see what feedback we will receive.
• resolution: Communities can extend JSON-FG and Records and if community extensions are widely used we can discuss including them in the standard (or an extension). For now it seems reasonable to restrict the scope to the most important use cases (instant and interval).

[cportele]

Meeting 2022-11-14: We will move this to waiting for feedback for now. In general, we could also close the issue for version 1.0.