Post by dmitry on Jan 3, 2020 8:14:17 GMT
Hi everyone,
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.
With regards,
Dmitry
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.
With regards,
Dmitry
