Time ordering of Coverages in a Collection

In the particle tracking use case and drift models, the usual outcome is set of:

• trajectories - from drift models they are identifiable along the time, something like NCEI Multiple mooring lines with stationary instruments at different depths across the mooring lines and the instruments measuring at different points in time. but without 'z' in dim.
• series of snapshots, each snapshot is a MultiPoint, each point has properties - good for raw observations, particles are not identifiable at source, also preference for visualization as it allows for present frame by frame.

Here is the covjson schema compliant second representation as CoverageCollection of MultiPoint, each Multipoint at different time:
https://github.com/ILIAD-ocean-twin/data_access_api/issues/12

Traversing through all the Coverages/frames to know what are the timestamps and to order them does not feel like elegant.
So example has additional time domain (not breaking the schema nor mentioned in spec as MAY for CoverageCollection) on the collection level where all the timestamps are listed and sorted. It is redundant to timestamps in the Coverages while allowing to construct timescale, potentiallyy faster (all timestamps in one block, no need to traverse all the Coverages, esp they does not have to be in order).

Is that a good case to say what is the domain of the coverage collection if exists?
Is it a good candidate for #161 type profile?

Beginne damit, die verlinkte data_access_api issue #12, den Vorschlag für eine Zeitdomäne auf Sammlungsebene und den referenzierten Abschnitt der CoverageJSON-Spezifikation zu lesen. Bestimme, ob sortierte Zeitstempel der Sammlung und die Anordnung von Coverages in das Schema oder in ein #161-Profil gehören, und dokumentiere anschließend das vereinbarte Verhalten und die Abschlusskriterien.