I think it is because of parsing collisions. I don't really see
another point to obligate the hours in a date_time
2011/3/18 Ian McNicoll <Ian.McNicoll at oceaninformatics.com>:
> Thanks Peter / Thomas,
> This is quite important and I had not appreciated the limitations on the use
> of partial dates with DV_DATE_TIME. I would agree that DV_DATE_TIME +
> DV_TIME would be very unusual but it is a very common requirement in
> clinical systems to be able to supply a vague date - year only or year +
> month and from what you say DV_DATE_TIME will not allow this, unless an hour
> is also supplied.
> I am struggling to understand the reason for this restriction in??ISO
> 8601:2004 - if the date is vague, what is the point of having any time at
> all!! Though I suppose the use case might be - "It was a cold dark December
> night and the clock has just struck 23:00".
> Having to add a DV_DATE constraint seems horribly clumsy. Perhaps we just
> need to make it clear than in?implementation, some sort of dummy time is
> added. In clinical terms this will always be meaningless?except in
> exceedingly rare circumstances.
> Ian
> Dr Ian McNicoll
> office +44 (0)1536 414994
> fax +44 (0)1536 516317
> mobile +44 (0)775 209 7859
> skype ianmcnicoll
> ian.mcnicoll at oceaninformatics.com
>
> Clinical analyst,?Ocean Informatics, UK
> openEHR Clinical Knowledge Editor www.openehr.org/knowledge
> Honorary Senior Research Associate, CHIME, UCL
> BCS Primary Health Care ?www.phcsg.org
>
>
>
> On 18 March 2011 11:48, Thomas Beale <thomas.beale at oceaninformatics.com>
> wrote:
>>
>> On 18/03/2011 11:10, Moretti Leonardo wrote:
>>
>> When we define a C_DATE_TIME element like this
>> ELEMENT[at0061] occurrences matches {0..1} matches { -- Date/Time element
>> ??? value matches {
>> ??? ??? DV_DATE_TIME matches {*}
>> ??? }
>> }
>> we said that element at0061 can contains a Date/time value, a date only or
>> a time only (indeed Archetype Editor show the label "Allow all").
>>
>> not quite right - it can only contain a DV_DATE_TIME. Valid DV_DATE_TIMEs
>> include instances with no time, e.g. '2011-03-18T11'. According to ISO
>> 8601:2004, date/times with 'reduced accuracy' must contain a complete date,
>> and at least the hour part of the time. So you can't have just a date, nor
>> just a time.
>>
>>
>> From the point of view of RM instances, this means we can have
>> <value xsi:type="DV_DATE_TIME">
>> ? <value>2011-03-18T11:01:28</value>
>> </value>
>>
>> but also
>>
>> <value xsi:type="DV_DATE_TIME">
>> ? <value>2011-03-18</value>
>> </value>
>>
>> this is illegal in ISO 8601 (and therefore openEHR)
>>
>>
>> and
>>
>> <value xsi:type="DV_DATE_TIME">
>> ? <value>11:01:28</value>
>> </value>
>>
>> also illegal.
>>
>>
>> Or for the latter we need to use DV_DATE and DV_TIME rescpectively
>> (remember we have defined a C_DATE_TIME constraint in archetype)?
>>
>>
>> you can technically do the following:
>>
>> ELEMENT[at0061] occurrences matches {0..1} matches { -- Date/Time element
>> ??? value matches {
>> ??? ??? DV_DATE_TIME matches {*}
>> ??? ??? DV_DATE matches {*}
>> ??? ??? DV_TIME matches {*}
>> ??? }
>> }
>>
>>
>> but I would suggest that allowing DV_TIME only would be very unusual if
>> not an error.
>>
>> - thomas beale
>>
>>
>>
>> _______________________________________________
>> openEHR-technical mailing list
>> openEHR-technical at openehr.org
>> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>>
>
>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
>
>
