You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are actually using an enumeration with a small set of defined durations (which of course could be extended).
Although the text in an enumeration is arbitrary, we aligned these with how those durations would be specified in RFC 3339 (and ISO8601).
However, you are right. In ISO8601 "M" is used for both months and minutes, because they are used positionally (in separate date and time components). You would specify "P1M" for a month and "PT1M" for a minute - with "T" separating date and time.
We could address this by changing the description to say:
Durations used for aggregations (1 day, 1 hour, 24 hours, 96 hours, 1 week, 1 month)
Or we could change the enum values to be clearer:
"P1D", "PT1H", "PT24H", "PT96H", "P1W", "P1M"
Meeting 2025-01-22:
We preferred to either a) align the enum values with ISO8601 and update the description to explain them OR
b) make the enum values more explicit: "1 Day" "Last 24 hours" etc (and not use ISO8601).
To discuss further.
Meeting 2025-01-23:
Use the enum values suggested above which align with ISO8601 and also
Clarify the "description" to make it clear what each mean: (1 day (from midnight), 1 hour, [last] 24 hour period, 96 hour period, 1 week, 1 month)
@cookeac In the observation-summary-metrics endpoint the duration details states M=Month and M=Min. Is the M=Min just a typo? Should not be there?
Originally posted by @jdoemel in #504 (comment)
The text was updated successfully, but these errors were encountered: