Clarification on timezones - UTC versus local times and offsets

[scottyhq]

https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#properties-object states that datetime requires UTC, but not very emphatically:

REQUIRED. The searchable date and time of the assets, in UTC. It is formatted according to RFC 3339, section 5.6. null is allowed, but requires start_datetime and end_datetime from common metadata to be set.

I'm used to seeing UTC times in metadata, but it's also convenient to have the timezone information somewhere to easily convert to local time without relying on location-based lookups. "time-numoffset" according to (https://tools.ietf.org/html/rfc3339#section-5.6)

This came up in a discussion of how to structure libraries that load in data from STAC records. Essentially, is it safe to assume times will always be UTC? https://github.com/gjoseph92/stackstac/issues/2#issuecomment-822651315

[scottyhq]

Also copying over the comment from @m-mohr in the issue linked above:

I'm not sure myself. I'd suggest opening an issue in stac-spec with a use case description so that we can discuss there. I could imagine that this is a legacy thing that we still want to change, although start_datetime and end_datetime also require UTC. On the other hand, created and updated don't require UTC.

I was mostly interested in properties:datetime but i could see an advantage in enforcing consistency and stating in bold that all times in STAC metadata should be in UTC. Which would also eliminate the possibility of storing valid ISO8601 strings like '2018-10-28T01:30:00+02:00'. And having code that ingests STAC do conversions such as (pandas.to_datetime('2018-10-28T01:30:00+02:00').tz_convert('UTC'))

[m-mohr]

ToDos:

• If we decide on all UTC, we should add the requirement to the timestamp extension + created + updated. We should also add something to the JSON Schema that checks it, e.g. a pattern like /Z$/ or so.
• If we decide against UTC, we need to remove it from datetime + start/end_datetime.

[cholmes]

I think enforcing UTC is more in line with the general STAC philosophy - have the 'main' thing be clear and easy. We use GeoJSON, and don't get into projections for the main geometry stuff.

But agree we should emphasize it more.

I think for easy conversion to local time I could see an extension that helps with that. Lets you add more datetimes in local time zones or something... But I prefer making the default path simple, and not allowing more options that force more complexity on every client.

[m-mohr]

It's all UTC now.