While reading the Redfish specification (1.8.0) I bound to a problem related to the Duration values. The Redfish specification refers to ISO 8601 duration notation where the duration may consist of data and time parts.
While the time part doesn't cause any uncertainty, the date part causes. This is because the nominal days, weeks, months and years in a duration may mean different exact values depending on the start point for the duration.
The amount of days in the months depends on what month is the starting one, the amount of hours in a day may depend on the DST transition, the year may be a leap year.
I could not find whether the ISO 8601 resolves these ambiguities. What I saw is that it uses the duration notation for defining time intervals where duration is combined with the starting time point and where there are no ambiguities.
So, since the specification assumes usage of duration values separately from staring points, I believe that the related ambiguities should be somehow clarified in the specification. For example: a day would mean 24 hours regardless of possible DST transition, a month is 30 days, and a year is 365 days. Or, maybe restrict usage of days/weeks/months/years in some applications, or define exact values for each application separately.
This is interesting. The duration format we leveraged if from the OData definition (in OData CSDL, the type is Edm.Duration). Looking deeper into this, OData restricts the usage to only go up as high as "days"; months, weeks, and years are not allowed to be represented. I think we need to take a closer look at this since our specification does not match the OData usage.