Definition of a ISO-8601/Gregorian TRS, and possibly redirecting uom/ISO-8601/0/Gregorian to it

[jerstlouis]

In Coverages SWG discussions it came up that it is not clear what TRS to use for ISO-8601 Gregorian Date+Time, as typically used with OGC APIs (Common, Features, Coverages...). Because of this, the AnsiDate and UnixTime TRS end up being misused, as the only available options.

On the Temporal DWG mailing list, @cportele indicated that Common & Features reference http://www.opengis.net/def/uom/ISO-8601/0/Gregorian as the identifier for the TRS, even though it was mistakenly (or not?) classified as a unit of measurement.

This issue is to properly define an ISO-8601/Gregorian temporal reference system, based on the proleptic Gregorian calendar (UTC time scale), that can represent both date & time. ( http://www.opengis.net/def/crs/ISO-8601/0/Gregorian_UTC ?)

We also suggest that http://www.opengis.net/def/uom/ISO-8601/0/Gregorian can redirect to it, and that http://www.opengis.net/def/trs/ISO-8601/0/ list is as its member rather than the uom URI.
[Edit: Not sure exactly what should be done about this in light of recent clarifications.]

Example E.4.1 in 19111/Topic 2 (https://docs.ogc.org/as/18-005r4/18-005r4.html#118) could be used as a starting point.
The axis abbreviation is listed there as uppercase T.
An alternative suggestion is to use time.

[jerstlouis]

First attempt at a GML definition (partly based on https://docs.ogc.org/as/18-005r4/18-005r4.html#118):

<?xml version="1.0" encoding="UTF-8"?>
<TemporalCRS
   xmlns="http://www.opengis.net/gml/3.2"
   xmlns:epsg="urn:x-ogp:spec:schema-xsd:EPSG:1.0:dataset"
   xmlns:gml="http://www.opengis.net/gml/3.2"
   xmlns:xlink="http://www.w3.org/1999/xlink"
   xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
   gml:id="gregorian-crs"
   xmlns:gco="http://www.isotc211.org/2005/gco"
   xmlns:gmd="http://www.isotc211.org/2005/gmd">
  <description>Concrete temporal CRS for date and time specified according to proleptic Gregorian calendar and the Coordinated Universal Time (UTC) scale.</description>
  <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/crs/ISO-8601/0/Gregorian_UTC</identifier>
  <name>DateTime in proleptic Gregorian calendar, UTC time scale</name>
  <remarks>Initial version (0.1)</remarks>
  <scope>Date/time as defined in ISO 8601.</scope>
  <timeCS>
    <TimeCS gml:id="gregorian-cs">
      <description>1D coordinate system containing a time axis specifying date and time.</description>
      <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">%datetime-cs%</identifier>
      <remarks>As defined in ISO 8601.</remarks>
      <axis>
        <CoordinateSystemAxis gml:id="gregorian-cs-axis" uom="http://www.opengis.net/def/uom/SI/second">
          <description>Coordinate system axis for Gregorian date and time.</description>
          <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">%dateTime%</identifier>
          <remarks>As defined in ISO 8601.</remarks>
          <axisAbbrev>time</axisAbbrev>
          <axisDirection codeSpace="http://www.ietf.org/rfc/rfc3986">http://www.opengis.net/def/axisDirection/OGC/1.0/future</axisDirection>
        </CoordinateSystemAxis>
      </axis>
    </TimeCS>
  </timeCS>
  <temporalDatum>
    <TemporalDatum gml:id="gregorian-td">
      <name>Proleptic Gregorian calendar</name>
      <description>Epoch time for the Gregorian calendar is May 20th, 1875.</description>
      <calendar>prolepticGregorian</calendar>
      <identifier codeSpace="http://www.ietf.org/rfc/rfc3986">%gregorian-td%</identifier>
      <remarks>The origin is by convention the calendar day that the “Convention du Mètre” was signed in Paris.</remarks>
      <scope>Date/time as defined in ISO 8601.</scope>
      <origin>1875-05-20T00:00:00Z</origin>
    </TemporalDatum>
  </temporalDatum>
</TemporalCRS>

NOTE: I suggest we explicitly allow both years 0000..1582 (where 0000 is 1 BC), as well as negative years (e.g. -0001 is 2 BC), up to 12 digits to also support older dates all the way back to the age of the universe (with the understanding that precision is greatly reduced the further away in the past from 1875), and that this constitute the mutual agreement required by ISO 8601 to use such older dates.

[cportele]

I think we should define this in http://www.opengis.net/def/crs/ISO-8601/0/Gregorian ("crs" instead of "trs").

The use of TRS is really outdated and, I think, has its source in the term "temporal reference system" in ISO 19108:2002. In 2018 ISO 19111/Topic 2 have been updated to include the concept of temporal coordinate reference systems as another subtype of CRS.

It seems appropriate to deprecate the "trs" register and going forward use the "crs" register for any temporal coordinate reference systems.

[cportele]

There is the general problem that the GML CRS encoding does not support all the latest changes in 19111/Topic 2. For example, I do not think that TemporalDatum in GML 3.2 includes a calendar element (where the value should be another definition in the Definition server - I think it is a codelist value in 19111/Topic 2).

In general, I would suggest to migrate the CRS definitions to WKT / PROJJSON. And/or define the necessary XML extensions to support the latest version of 19111/Topic 2.

[ghobona]

@alexrobin

SWE Common 2 references a number of temporal reference systems from the http://www.opengis.net/def/trs/ branch.

If the branch were to be deprecated, the existing URIs would still be there but we would not add any new items to the register. Instead any new temporal reference systems would be added to the http://www.opengis.net/def/trs/ branch.

Would there be any adverse impact on SWE?

Cc: @chris-little @rob-metalinkage @nicholascar

[pebau]

@ghobona did you mean to say "would be added to the http://www.opengis.net/def/crs/ branch" ?

Applauding to the support for the idea to have all CRSs in the crs/ branch!

And great that the information is machine-readable and hence paves the way for transformations between future time CRSs and calendars.

[alexrobin]

I would like to point out that http://www.opengis.net/def/uom/ISO-8601/0/Gregorian was not mistakenly classified as a unit of measurement. It was originally defined by SWE Common to be used as a system of units, not a CRS/TRS, as stated in the definition.

Composite unit (century, year, month, day, hour, minute, second, millisecond) defining the scale for the gregorian calendar used in ISO 8601. Note that this just identifies the scale and can be used with different time reference systems (UTC, UT1, GPS, TAI, etc.).

So it's different from http://www.opengis.net/def/crs/ISO-8601/0/Gregorian that is meant to be a complete 1D CRS (reference point + scale).

If we want to create a temporal CRS definition based on ISO8601 I would actually create several ones that explicitly list the time scale in the name, e.g. http://www.opengis.net/def/crs/ISO-8601/0/Gregorian_UTC, as ISO8601 timestamps are often used with UTC but also to report on TAI and GPS time scales. For precision time stamping it's quite important as there are several tens of seconds difference (see http://leapsecond.com/java/gpsclock.htm).

@ghobona I see no issue deprecating the 'trs' branch as long as the old URIs still point to the new ones we create. What I'm not sure about is if the 'crs' branch is the right place for TAI, GPS, UTC, etc. since, technically speaking, those are are time scales.

[alexrobin]

Note that the definition of http://www.opengis.net/def/uom/ISO-8601/0/Gregorian should be improved because it creates confusion between temporal units and time scales.

If think we should rewrite it to say:

Composite unit (calendar units century, year, month, day, hour, minute, second, millisecond) as used in the proleptic Gregorian calendar described in ISO 8601. Note that this just identifies the temporal units and can be used with different time scales (UTC, UT1, GPS, TAI, etc.).

[ghobona]

@alexrobin Thanks for the background.

So a draft 'Motion on Temporal Coordinate Reference Systems' for consideration during the next OGC-NA meeting would look like this:

The OGC-NA agrees to update the registration of Temporal Coordinate Reference Systems as follows:

• Revise the definition of http://www.opengis.net/def/uom/ISO-8601/0/Gregorian as per the rewrite proposed by @alexrobin in Definition of a ISO-8601/Gregorian TRS, and possibly redirecting uom/ISO-8601/0/Gregorian to it #101 (comment)
• Leave the concepts under http://www.opengis.net/def/trs where they are.
• New registrations of temporal reference systems, if they fit the definition of a temporal CRS, would be registered under http://www.opengis.net/def/crs

[jerstlouis]

@ghobona I would like the motion to specifically reference the registration of a new general-purpose ISO 8601 / proleptic Gregorian calendar / UTC time scale TRS (http://www.opengis.net/def/crs/ISO-8601/0/Gregorian_UTC). I have adjusted the draft GML definition per @alexrobin's suggestions above.

[cportele]

I don't see how the unit definition works. Unless we change the concepts of Measure and Unit of Measure, entries in the UoM register are units associated with a numeric value where values are continuous in the numeric range of the unit.

That works for POSIX time, but ISO 8601 does not specify Units of Measure, it specifies representations of time that are (intentionally) not a number.

Yes, for a time scale one could specify rules that convert the ISO 8601 representation to a numeric range without discontinuities, but that is not specified by ISO 8601 and the registration would belong to a different authority - and the conversion needs to be specified first by someone (the authority).

[nicholascar]

TRSes need proper handling and should not be part of CRS. In fact, in GeoSPARQL revision, we have dropped the term “CRS” in favour of SRS since we have spatial reference systems that don’t use coordinates. e.g. DGGSes.

The Australian government has a growing list of TRSes https://linked.data.gov.au/def/trs which I have previously asked the OGC to take over (so far unresolved). We expect that the list will grow in both size and importance as modelling systems such as OWL-TIME become more widely used alongside systems such as GeoSPARQL. We also expect GeoSPARQL 2.0 (still a year or two away) to handle both spatial and temporal, in fact GeoSPARQL might be renamed.

So please don’t retire TRS and please don’t subsume TRS into CRS.

[pebau]

@cportele The Temporal.DWG has worked out the difference between calendar (that's what 8601 and Gregorian are) and a time CRS sensu strictu (count in seconds since epoch).

Generally, uoms that are not strictly floats happen already with degrees / minutes / seconds which are converted to decimal degrees routinely. The same can be done with a calendar-to-seconds mapping, based on the existing definitions.

So no reason the space-time continuum that physics is aware of cannot also be adopted by Earth sciences :)

[cportele]

@pebau, that is what I wrote, one can convert those other representations to units (Measure has two properties, value is a Number and uom is a UnitOfMeasure). But then the unit is seconds in some continuous time scale and the authority is not ISO 8601.

And degrees with minutes/seconds is also not a unit, decimal degrees, radians, gon are.

[pebau]

@cportele Here is an interesting point, can you help and explain maybe? You say deg/min/sec is not a valid uom, but I seem to remember having seen them as allowed as substitutes for decimal degrees. In some GML CRS comments I found a mentioning, but I am not aware of the formal handling in CRSs. Is there some precedent which we maybe could apply also to Gregory?

[cportele]

@pebau

• I do not see how one can encode a GML 3.2 CRS or geometry with non-numeric axes. Each coordinate in a geometry is a list of doubles and the values type of each coordinate axis is numbers within a range. This also applies to TemporalCRS and TimeCS.
• Conceptually, this was not different in GML 2.1, but since coordinates were encoded as a string and had options to change the separators etc. one could technically also encode non-numeric values and this was sometimes done (e.g. as deg/min/sec).
• A similar approach is also possible in GML 3.2 as long as the lexical value conforms to an xs:double even though these aren't numbers where the normal arithmetic expressions work. An example are the sexagesimal values which encode deg/min/sec values as a string that looks like a number. EPSG has registered this as a "pseudo unit" under "uom" (http://www.opengis.net/def/uom/EPSG/0/9110), so technically one can use this in a CRS and a GML document which uses sexagesimal coordinates would look correct and pass schema validation, but conceptually would not be valid GML and most libraries will not interpret such "coordinates" correctly. I think it is at least 15 years since I have seen such files, but maybe some are still using hacks like these.
• The revision of Topic 2/ISO 19111 in 2018 updated the conceptual model. One of the changes was to add support for temporal coordinate reference systems. This required that it is no longer true that every coordinate axis is numeric. For TemporalCS there are three subtypes,: one for ISO 8601 datetime values (constraint: no associated unit), one for integer-based and one for float-based values. See Topic 2.
• I.e., the concepts are specified and we should use that as the basis for our registrations. Which is also why I still think that TemporalCRS registrations belong to the "crs" register.
• From an implementation point of view, there are some open issues for OGC:
  • The GML CRS encoding does not support the current abstract spec and it will not be possible to use the GML 3.2 CRS encoding to encode Temporal CRSs (see my comment about this earlier in this discussion). This requires either a migration to WKT and PROJJSON (my preference) or to define XML extensions to the GML 3.2 CRS schema to support the current abstract spec. Or both.
  • For cases where a CRS uses a coordinate axis that has a non-numeric datatype (currently, I think, ISO 8601 datetime values are the only case) then you cannot encode such geometries, for example, in GML or in WKT geometries (encoding the time as M values). I think there are two options: either specify new standards to encode spatio-temporal geometries or encode spatio-temporal geometries in CRSs that do not use a ISO 8601 representation of time (DateTimeTemporalCS), but a proper measure (TemporalMeasureCS). To me, the second option looks much more promising.

[alexrobin]

@cportele I know that defining ISO8601 calendar as a UoM may seem odd but the idea was indeed to define a pseudo unit similar to degrees/minutes/seconds of http://www.opengis.net/def/uom/EPSG/0/9110. We chose ISO8601 as the authority because the standard does (re)define Gregorian calendar units in section 2.2, in addition to their string representation.

As @pebau said I believe information provided in ISO8601 standard + a timescale is enough to convert an ISO8601 representation to its equivalent "seconds past epoch" without ambiguity, and that's what most time libraries do (e.g. Java 8 time), so I'm not sure we need to add complexity here.

The ISO8601 UoM allows SWE Common to reuse the same class for carrying time values as decimal numbers past an epoch or ISO8601 datetime. In the end the intent is similar to what is now described in Topic 2, just with a slightly different model.

[alexrobin]

Just to clarify, I'm not saying using the ISO8601 calendar as a UoM is the perfect model, I'm saying it's choosing pragmatism vs a more complex - perhaps "closer to perfection" - theoretical model.

And I don't think this choice is any worse than what is proposed in Topic 2 (i.e. a separate temporal CS class to encode values as ISO8601). The point is that in both cases there is an implied transformation to go from ISO8601 to a scalar value along the temporal axis, and that transformation is indeed not explicitly defined by ISO8601.

[pebau]

@alexrobin @cportele glad that we seem to converge on a pragmatic solution! In parallel to a machine-readable set of definitions we might set up a best practice paper, I am willing to get my hands dirty.

[pebau]

@cportele re GML, yes, I am more than aware of the issues - we had years and years of discussion since about 2010 to convince OGC folks that users will not want 15-digit second counts, but 8601 strings. Today this is more commonly acknowledged than it was, but of course we have the legacy of GML. Maybe an update could be done? Just as a side note, in CIS 1.1 such strings are allowed and easily parseable in XML, JSON, and RDF.

Which gives a broader perspective - these days JSON is trending, and I hear SKOS activists speak up, so pragmatically we might accept that canonical GML is constrained (at least for now, until an update) and go ahead with the desired solution.

Just to observe the growing number of non-numerical cases: we have now deg/min/sec and date, but there is also flight levels in aviation, like "FL050". I am sure we can find more use cases.

[chris-little]

Dear Temporal and Naming Enthusiasts, Minor edits for clarity.
I have been catching up with this interesting conversation containing a few separate threads, on both mailing lists and GitHub and trying to understand it. Here is my summary, which tries to connect to the basics, and I hope will be helpful. Apologies if it seems slightly 101. And please count to 10, in unspecified units, before hitting the keyboard ;-)

1. Spatial Reference Systems (SRS) such as addresses and postcodes, DGGS, What3Words, etc, are rooted in the OGC Abstract Topics and ISO. This seems stable and accepted.

2. A specialised SRS is the Coordinate Reference System (CRS), also a specialisation of Coordinate Systems (CS), and again rooted in the OGC Abstract Topics and ISO and also the fundamentals of mathematics.

A CRS has:

• an origin,
• a datum to anchor the CS to a object,
• one or more dimensions/axes, and for each dimension/axis:
  • agreed direction,
  • a Unit of Measure,
  • a valid range of values, such as from (-∞ to +∞), (0 to 2π), or (0 to 180 degrees of arc).
• the mathematical assumption that normal rules of arithmentic apply to coordinate values and each axis is equivalent to the real number line, and intermediate values can be 'interpolated'.

I think there is probably consensus on this and it is stable and accepted.

3. Units of Measure (UoM) are rooted in physics and each is a single 'atomic' entity, as listed in QUDT or UCUM. For convenience and appropriate accuracy and precision, multiples of the UoM are usually by numeric powers of ten, as in the Système Internationale (SI).

Perhaps the only aspect not well understood is that 'dimensionless' units ('dimensional' in this case referring to Mass, Time, Length) have a dimension of 1 (one) not 0 (zero). This aspect enables better (automatic) comparison of values from disparate domains.

So far, so good, and I think consensus and stability apply.

However Degrees of Arc/Minutes of Arc/Seconds of Arc slightly break this model by having multiples of 60 rather than 10, so it is not clear whether this is one or three UoMs. Decimal Degrees of Arc, Minutes of Arc or Seconds of Arc by themselves clearly conform to the strict definition of UoM.

4. Temporal rather than Spatial is not so clear cut. There are Temporal Reference Systems that are not coordinate based, such as geological or archaeological layers, ice or mud cores, King lists, etc. This is consistent with the W3C Time Ontology. It is analogous with the SRS ideas above. I think that the OGC NA should plan to possibly register in this area, as some appropriate bodies such as BIPM and IERS did not think it within their remit. I may be out of date though.

5. There are Temporal Coordinate Reference Systems which are CRSs exactly as in (2) above, with the same properties. @pebau and others did a good job in registering them with the OGC NA. The only noticeable difference is in terminology - the Datum is usually called an Epoch.

I agree with @pebau that such TCRS are just CRS and should be defined in the same /CRS/ branch of the registry. This then allows the straightforward definition of spatial-temporal CRSs, as assumed by WCS/CIS.

6. Should a calendar such as the Gregorian, assumed and mandated by the ISO8601 notation, and numerous restrictive or extending profiles, be considered a CRS with a complicated UoM? Calendars fail the CRS definition by not having the normal rules of arithmetic, and a single simple UoM.

Timestamps based on the ISO8601 notation and a single clock can be unambiguously sorted into temporal order, but calculating durations (lengths in time) is not guaranteed to give unambiguous results as they depend on exactly which calendar algorithms are used. These vary even just for the Gregorian calendar.

Summary: I propose that the OGC NA deprecate the UoM/Gregorian branch, and establish a TRS branch for temporal reference systems, which would include calendars.

This branch would then contain the root definition of, for example, datetime.

And all true CRSs would be in the CRS branch.

[nicholascar]

There are Temporal Reference Systems that are not coordinate based, such as geological or archaeological layers, ice or mud cores, King lists, etc. This is consistent with the W3C Time Ontology. It is analogous with the SRS ideas above. I think that the OGC NA should plan to possibly register in this area

This is consistent with my wishes and the example TRS vocab I linked to above!

We could ask for people to define/characterise non TCRS TRSes and register those. Some of the important ones, like Geological Timescale, are already well characterised and we have good relations with their primary users (I am webmaster of the International Commission on Stratigraphy).

centralising a listing of TRSs, including very different ones like imprecisely defined King Lists would be a real data service for the Semantic Web world.

[ghobona]

Some additional background.

There are some definitions of instances of gml:TemporalCRS that are already registered under the crs branch. For example:

• Chronometric Geologic Time , http://www.opengis.net/def/crs/OGC/0/ChronometricGeologicTime
• AnsiDate, http://www.opengis.net/def/crs/OGC/0/AnsiDate

There are also some broader temporal reference systems registered under http://www.opengis.net/def/trs

The following extracts from the GML 3.2.1 Standard are also relevant. They are also in the GML 3.2.2 Standard.

gml:TemporalCRS is a 1D coordinate reference system used for the recording of time (Clause 12.3.3.33 of OGC 07-036).

gml:TimeCS is a one-dimensional coordinate system containing a time axis, used to describe the temporal position of a point in the specified time units from a specified time origin (Clause 12.4.4.7 of OGC 07-036).

A value in the time domain is measured relative to a temporal reference system .....In GML seven concrete elements are used to describe temporal reference systems: gml:TimeReferenceSystem, gml:TimeCoordinateSystem, gml:TimeCalendar, gml:TimeCalendarEra, gml:TimeClock, gml:TimeOrdinalReferenceSystem, and gml:TimeOrdinalEra (Clause 14.4.1 of OGC 07-036).

[pebau]

This is a very helpful compilation! Maybe we move forward defining the time CRS universe systematically and discuss its proper location later.

[alexrobin]

Yes I agree with @pebau that before we decide on an ontology branch to host these concepts, it seems we first need to clarify our model for time (i.e. temporal reference systems, calendars, time scales, etc...).

[chris-little]

@alexrobin I have just started populating a [GitHub repo for an Abstract Spec/Conceptual Model for Time](https://github.com/opengeospatial/Temporal-Abstract-Spec, hopefully consistent with OWL-Time.

Technically though, the Temporal Domain WG can only generate Best Practices, Engineering Reports etc. We need a Standard WG chartered to do that, but at least it is somewhere to start.

Technically, OGC policies state that we are not meant to start substantive work untillthe SWG Charter is approved.

Volunteers welcome to help crack this problem. Anyone want to step up as co-chair of the Temporal DWG?

[pebau]

Coverages are dealing with time, all the time. Additionally, as coverages are multi-dimensional, there is a sense about the necessary coherence of mechanics across dimensions. Hence, the Coverages.SWG is the natural carrier WG.

[ghobona]

@chris-little The OGC-NA will wait for the Temporal DWG to advise on a way forward regarding this topic.

[jerstlouis]

@ghobona @chris-little It would be great if that could be discussed at the upcoming Temporal DWG session.
I really feel like we are missing this critical piece: a simple Gregorian / UTC temporal reference system, which can support all basic temporal needs of OGC APIs, but also through which we can easily convert any other temporal system, much like WGS84 can act as the fallback for geospatial conversions when no direct conversion is defined.

[chris-little]

@jerstlouis I, and many others I am sure, have serious problems with those two adjacent words: simple Gregorian.

[jerstlouis]

@chris-little Yet we all use the Gregorian calendar in our every day life in a rather simple way!
And many software implementions (e.g. java.time) provides time functionality simple enough to use as well.

There must be a way to make progress with this. We need to, as OGC API needs a simple yet proper solution for temporal support.

I believe the way forward is:

• Define a temporal reference system based on the proleptic Gregorian calendar and UTC time scale
• Correct conversions to and from other temporal system can be defined (e.g. highlighting differences between Julian and proleptic Gregorian calendar dates)
• Properly document the inherent limitations and imprecisions of any conversion or of the use of this temporal system in general for years further away in the past

So it can be simple: an ISO8601 string unambiguously referring to any specific moment in time.
And it can be converted as accurately as possible to and from other temporal reference systems.

Of course by simple I mean, as simple as possible, but no simpler (maxim often attributed to Albert Einstein).

[rob-metalinkage]

Encapsulation is your friend.

We use Gregorian calendars happily enough in most cases because all the calculation logic is hidden behind functions (encapsulation) - rather than complex descriptions of how to and the internal data models to support these functions.

If there are differences in the functions that are required or possible, then possibly some sub-typing is required to distinguish these, otherwise canonical naming so the right implementation of these functions can be found is probably sufficient description.

[chris-little]

@jerstlouis I will add your bulleted points to the agenda for the Temporal DWG for discussion. Your points were part of the original intention of the draft Best Practices document.

As usual, "Simple ain't easy" - ISO8601 string unambiguously referring to any specific moment in time - for a start, "ISO8601" is ambiguous! Plenty of work for us, but at least we have some interested parties. :-)

[jerstlouis]

@chris-little while "ISO8601" is ambiguous, I hope "ISO8601" in the context of this new TRS can be disambiguated.

Thank you! :)

[chris-little]

@jerstlouis Over the years, the various versions of ISO8601 subtly altered things, like not allowing "Now", or "24:00" for a day as opposed to "00:00" for the following day, or removing references to "midnight". Lots of people sttill adhere ISO8601:2008 as that version is freely available in the public domain. HTH

[pebau]

https://www.opengis.net/def/crs/OGC/0 has several temporal definitions already.

[jerstlouis]

@pebau But none of them is for Gregorian calendar / UTC time scale.

AnsiDate and UnixTime imply a particular format of the date and time which is not the ISO 8601 / RFC 3339 commonly used with the OGC API standards.
For this reason, OGC API - Features specifies http://www.opengis.net/def/uom/ISO-8601/0/Gregorian as a CRS, but that is a unit of measure, not a CRS.

[ghobona]

This issue needs to be discussed by the Temporal DWG and resubmitted once a definition is available for registration.

Closing the GitHub Issue and moving it to the Temporal DWG mailing list.