4. The millisecond_validity field in C_DATE_TIME and C_TIME might be incorrectly named. In ISO 8601, the seconds fraction are not exactly milliseconds: .5 means half of a second, though it is 500 ms, the time expression doesn’t require to have the ‘500’, it also allows more digits, like .333333 is valid, which means 1/3 of a second. The name ‘seconds_fraction’ is correct in this case.
“There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties. For example, in Microsoft SQL Server, the precision of a decimal fraction is 3 for a DATETIME, i.e., "yyyy-mm-ddThh:mm:ss[.mmm]".” https://en.wikipedia.org/wiki/ISO_8601 (sadly I don’t have access to the full ISO 8601 spec).
hh:mm:ss[,sss][Z|+/-hhmm] -- a time with optional seconds
yyyy-MM-ddThh:mm:ss[,sss][Z] -- a date/time
ss,sss = seconds, incuding fractional part
6. Reading the ISO 8601 spec in the wikipedia, I found this “A decimal fraction may be added to the lowest order time element present, in any of these representations.“, so it is possible to have something like: T10:30.5 which is hour 10 and 30.5 minutes (yes 30 and a half minutes). It seems the decimal fraction applies to the lowest order component of the time section. Should this be supported?
I fixed few a small issues: point 1 and 2 from above; point 3 will be solved in BASE; the rest won’t be solved for now as they are more disruptive, or unclear.
Lowest
timezone_validity was added to C_DATE and shouldn't be there (TZ should only be in data with time expressions).
https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_c_date_class
2. In C_DATE_TIME it has a typo: timezone_valdity should be timezone_validity
https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_c_date_time_class
3. In C_DATE, C_TIME and C_DATE_TIME invariants, VALIDITY_KIND.
disallowedis used, though that is not defined, the correct value is “prohibited”: https://specifications.openehr.org/releases/AM/Release-2.2.0/AOM1.4.html#_validity_kind_enumeration4. The millisecond_validity field in C_DATE_TIME and C_TIME might be incorrectly named. In ISO 8601, the seconds fraction are not exactly milliseconds: .5 means half of a second, though it is 500 ms, the time expression doesn’t require to have the ‘500’, it also allows more digits, like .333333 is valid, which means 1/3 of a second. The name ‘seconds_fraction’ is correct in this case.
“There is no limit on the number of decimal places for the decimal fraction. However, the number of decimal places needs to be agreed to by the communicating parties. For example, in Microsoft SQL Server, the precision of a decimal fraction is 3 for a DATETIME, i.e., "yyyy-mm-ddThh:mm:ss[.mmm]".” https://en.wikipedia.org/wiki/ISO_8601 (sadly I don’t have access to the full ISO 8601 spec).
5. Small note on ADL: current spec gives the idea the comma is the only seconds fraction separator allowed but in ISO 8601 the period is also allowed, and none is preferred https://specifications.openehr.org/releases/AM/Release-2.2.0/ADL1.4.html#_complete_datetimes see:
hh:mm:ss[,sss][Z|+/-hhmm] -- a time with optional seconds yyyy-MM-ddThh:mm:ss[,sss][Z] -- a date/timess,sss = seconds, incuding fractional part6. Reading the ISO 8601 spec in the wikipedia, I found this “A decimal fraction may be added to the lowest order time element present, in any of these representations.“, so it is possible to have something like: T10:30.5 which is hour 10 and 30.5 minutes (yes 30 and a half minutes). It seems the decimal fraction applies to the lowest order component of the time section. Should this be supported?