UNIX (or POSIX) Time in Temporal Reference Systems

[KathiSchleidt]

At present, only TemporalRS with calendar as Gregorian is foreseen. How could I indicate that I'm providing time as UNIX (or POSIX) Time?

[jonblower]

I think this can be done if there is a URI that references Unix time. Is this a well-defined Temporal RS, and has someone minted a URI to denote it?

A more general solution would be to mimic CF-NetCDF and allow for temporal reference systems like "seconds since 1970-01-01".

[chris-little]

@jonblower @KathiSchleidt Th OGC registers have a definition but seem to have two of everything (CRS, Datum, parametrized CRS whatever that is)

[chris-little]

@ghobona The resolution of this issue is blocked by https://defs.opengis.net/prez/search?q=unix+time having two definitions of everything. When will Rainbox be trimmed down to one definition please?
A side issue is that no one know what Parametrized Unix Time is.

[chris-little]

@KathiSchleidt states that the schema is missing the relevant parts for a time axis (i.e. a start, stop, num). This implies the test needs fixing too.

[jonblower]

I think we also have to sort out what the spec is going to cover. Probably two options:

1. Allow the use of TemporalRS in which the values are numeric (e.g. Unix time), and the CRS is identified simply through a URI.
2. Allow a more general temporal RS in which we can specify the temporal datum and step length (e.g. "seconds since datum"), as in CF-NetCDF.

Or both of course! Supporting the first one is simpler - the second one adds a lot of value but will need a bit more specifying.

[chris-little]

@jonblower That looks like a two part plan - parts 1 and 2!

[jonblower]

Thinking about this, I'm not sure what to do with the calendar attribute if we're going to use Unix time. The spec is based around the use of strings to represent time values, which require a calendar to interpret them.

But if we use Unix time, we'll have numeric values, and there won't be any strings to interpret. Therefore:

1. We probably don't need calendar in this case (note that it's currently a mandatory attribute), and
2. We probably need a new attribute to point to the definition of the temporal RS.

Is there anything we can steal from other standards here?

[chris-little]

Is there anything we can steal from other standards here?
@jonblower I suspect not, as that was why I was motivated to produce the OGC Abstract Conceptual Model for Time. The current practice is to pretend that string notation and a calendar is a CRS like all the other CRSs. Witness the long, convoluted, theological, discussions in the CF-NetCDF community over the last years; or the OGC desire to label an ISO8601/IETF RFC3339 string as a CRS.

I agree that if a temporal CRS is being used, like Unix Time or TAI, calendar seems surplus, but it is needed to specify the epoch/datum of the temporal CRS. I think allowing other ways of specifying the datum (e.g. Aztec long cycle years, Julian days or years, etc) is a very bad idea.

So:

1. We do need calendar for the two uses cases: decoding the time string of the data, and decoding the epoch/datum string of the temporal CRS.
2. We probably need an attribute to point to, or contain, the temporal CRS definition.

PS The reason for OGC registers having seemingly multiple definitions of one thing has been identified. Not sure about fix yet.

[jonblower]

@chris-little that makes sense to me. Perhaps we could define a TemporalCRS objects that is a subtype of the current TemporalRS but looks a bit like this:

{
  "type" : "TemporalCRS",
  "datum" : "1970-01-01T00:00:00Z", // This would be an ISO-like string
  "calendar" : "Gregorian", // For interpreting the datum
  "interval" : "seconds", // This would come from a controlled vocabulary
  "direction": "future" // Could be "past" for geological calendars
}

Would that cover it? There are some controlled terms in there that we'd have to define, or take from another vocab (any suggestions)?

The alternative would be the slightly shorter but equivalent syntax from CF:

{
  "type" : "TemporalCRS",
  "definition" : "seconds since 1970-01-01T00:00:00Z",
  "calendar" : "Gregorian"
}

But I would suggest that the shorter version may be slightly harder for general clients to parse (although easier for CF-aware ones). We could also allow a URI that points to the CRS definition, for some common cases like Unix time.

[jonblower]

P.S. ChatGPT just generated the following suggestion, which is a bit more verbose but also looks good to me... spooky!

{
  "type": "TemporalCRS",
  "id": "urn:ogc:def:crs:OGC::UnixTime",
  "name": "Unix Time",
  "datum": {
    "type": "TemporalDatum",
    "origin": "1970-01-01T00:00:00Z",
    "calendar": "Gregorian"
  },
  "coordinateSystem": {
    "type": "TemporalCoordinateSystem",
    "axis": [
      {
        "name": "time",
        "direction": "future",
        "unit": "second"
      }
    ]
  },
  "extent": {
    "start": "1970-01-01T00:00:00Z",
    "end": null
  }
}

[chris-little]

@jonblower Both the non-CF apporaches are prefereable to the CF apporach which hides too much.
ChatGPT approach looks good in that is has axis, direction and unit.
Perhaps unit could be calleduom?
Does axis tie in with the other domain coordinates (no reason to be different)
name is also good, such as "ValidityTime", "ObservationTime", etc.
extent may be better in the CRS units. E.g. 0 to 1000 000 000 or whatever
type does this also corrrespond to the other domain CRSs ?

[jonblower]

@chris-little Agree that the CF approach makes parsing a bit more difficult and a more structured approach is better.

I guess ChatGPT's version is the most precise and has a more literal translation to ISO CRS definitions, although it contains pretty much the same information as my original, more compact version. I'm not sure the extent is really needed at all in practice - maybe this could be an optional addition? I agree that it might be better for the extent to be in CRS units.

Was there ever a conclusion on the separate work to generate JSON encoding of CRSs?