What do for geologic time extents?

[schwehr]

For data that covers geologic time, what should the temporal extent be set to?

https://github.com/radiantearth/stac-spec/blob/master/collection-spec/collection-spec.md#temporal-extent-object says

Timestamps consist of a date and time in UTC and MUST be formatted according to RFC 3339, section 5.6. The temporal reference system is the Gregorian calendar.

RFC 3339 doesn't handle times like 300 million years ago.

I can just set it to null for now, but that seems like a bummer for folks dealing with earth history data like sea floor ages, geologic unit ages, paleomagnetic samples, etc.

Yeah, I'm a geologist / geophysicist...

[schwehr]

See comment by @rabernat on my thread: https://twitter.com/kurtschwehr/status/1523781248912560129

The CF Time package and conventions might be useful here? https://unidata.github.io/cftime/

I found http://cfconventions.org/cf-conventions/cf-conventions#time-coordinate

Right you would have to use a different calendar. As in example 4.6 from CF conventions

[schwehr]

And then there is the question of temporal extent in tiffs... the conversation in the libtiff mailing list hasn't hit the archive yet, but will be here:

https://www.awaresystems.be/imaging/tiff/tml/tm202205.html

[philvarner]

ISO 8601 (from which RFC 3339 is derived) says:

To represent years before 0000 or after 9999, the standard also permits the expansion of the year representation but only by prior agreement between the sender and the receiver.[20] An expanded year representation [±YYYYY] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign[21] instead of the more common AD/BC (or CE/BCE) notation; by convention 1 BC is labelled +0000, 2 BC is labeled −0001, and so on.[22]

I think one thing I don't understand is how you have items that need temporal extents (and datetimes) in the past -- these should be when the asset was collected rather than the age of the rocks or whatever. I'd recommend adding a custom property that represents the age of whatever is in the image isntead.

[schwehr]

I use stac to represent the time of the data. If I pick up a rock from an outcrop, nobody really cares when I did that. They care that I processed a rock sample that is X million years old. In my dataset, I might have data that covers 1Ga to 250Ma. If that's not in the temporal extent, then how is one supposed to find the data? If I have a climate model that goes from 100 Ka to 10 Kyrs in the future, that should be in the extent, yes? Or do we need multiple temporal extent fields? If I do a hind cast of weather or ocean from the year 1990 today in 2022, what should the temporal extent be?

[matthewhanson]

Discussed in STAC sprint. From the spec:

This is likely the acquisition (in the case of single camera type captures) or the 'nominal' or representative time in the case of assets that are combined together.

In other words, it's sorta open-ended on what datetime means, and the provider can set this to the creation time of the metadata.

Then, create an extension with the additional time fields (geologic time, or other planetary times (e.g., LsubS)

The filter extension could then be used to search on any of these additional properties.