My ideas about this topic. Two distinct different times we need to consider: -Time (physical) at the system level to be used for Timestamps, including Time zone Chronos is the greek deity associated with it. A specific generic data type will deal with this. - Time as used by humans. Including Time zone but also things like week, autumn, midnight, and associated time relationships like before, after, during, overlapping, etc. The associated Greek deity is Chairos.
The Chronos Time is modelled using a data type. The Chairos Time is modelled via Archetypes using the Data Types but augmented with attributes taken from the proper ontologies. Gerard Freriks +31 620347088 gf...@luna.nl Kattensingel 20 2801 CA Gouda the Netherlands > On 19 Mar 2018, at 01:56, Pablo Pazos <pablo.pa...@cabolabs.com> wrote: > > Hi, > > I'm digging into the specs again, and testing the modeling tools to produce > different constraints for DV_DATE_TIME. > > When I analyzed the partial datetime pattern yyyy-mm-ddTHH:??:?? that allows > optional minutes and seconds, and the constraints that would correspond to > "any allowed" it seems both are the same. I'll explain. > > "any allowed" for DV_DATE_TIME would be any value that actually is a > datetime. For instance "1999-01-01" is not a datetime, so "any allowed should > check for datetime that at least has hours, that is something like > "1999-01-01T16". > > Having "1999-01-01" as a datetime would be a type mismatch if we are strict. > With relaxed rules we can say "1999-01-01" is equivalent to > "1999-01-01T00:00:00", but we are assuming something that might not be the > intent of the user that inputs the data. Since this is health date, I prefer > the strict approach. > > But if we have the partial datetime pattern, that is validating the same, > that at least the hours are there, then minutes and seconds are optional. > > Invalid datetime like "546454" won't be valid on any allowed or partial > pattern > Date only like "1999-01-01" won't be valid on any allowed or partial pattern, > since it is not a datetime, is date > Date with hours, will be valid on both > Date with hours and minutes, will be valid on both > Date with hours, minutes and seconds will be valid on both > (on all cases timezone information can be added, if it is not present, UTC is > default) > > > Considering this, it seems both are equivalent. So why allow both? > > IMO this generates a point where implementers can have different > interpretations and implement both constraints in a different way (any > allowed and partial pattern). > > > What do others think? > > > Thanks! > > -- > Ing. Pablo Pazos Gutiérrez > pablo.pa...@cabolabs.com <mailto:pablo.pa...@cabolabs.com> > +598 99 043 145 > skype: cabolabs > <http://cabolabs.com/> > http://www.cabolabs.com <http://www.cabolabs.com/> > https://cloudehrserver.com <https://cloudehrserver.com/> > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > _______________________________________________ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
