Louis Visser wrote:
>Dear Thomas, > >I happened to note your email below. I do not follow in detail the >project you are involved with, but noted the format you intend to >use for date and time notation. >This format at ill feet with the international standard on >this subject: ISO 8601. In that standard the example in your >email would be 1940-01-01+10:00 (or 19400101+1000) > Actually, the text rendering of all dates and times in openEHR is ISO 8601 compliant, although I can't remember if we have stated this in the text (it's in the XML schema for example). I'll check this. My use of dates like "1/1/1940" below is purely informal. >My suggestion would be that for this topic your group considers the >applicability of the existing international standard before introducing >a new (and substantially different) format. > we have no interest in introducing a new format, but one thing to realise is that the ISO8601 format is for _representation_ not computation. The classes we have defined in the model are agnostic about representation internally, they are there to define semantics. But I should definitely improve the explanation in the text. > > >Kind regards, >Louis Visser > > > > >>>>Thomas Beale <thomas at deepthought.com.au> 08/28/02 08:41am >>> >>>> > >A few weeks ago, we inserted the class DV_WORLD_TIME into the data >types, as a parent of all date & time types measuring real world >(absolute) time, i.e. all of the types except DV_DURATION which just >measures a time difference or length, however you like to think of it. > >Currently DV_WORLD_TIME has only one feature of its own - >timezone:DV_DURATION. (To see a UML diagram of what I am talking about, > >go to section 6.1 of >http://www.deepthought.com.au/health/openEHR/data_types_1_5_3_clean.pdf). > >Sam Heard has pointed out that timezone does not make any sense for >pure >dates (DV_DATE), only for DV_DATE_TIME or DV_TIME, since DV_DATE has an > >implied "error" of 24h, and there is no possibility of comparing two >DV_DATEs and taking into account their timezone (except in the >probabilistic sense, if you were to compare many of them). For example, > >there is nothing useful you can do with the timezone information in the > >dates 1/1/1940 +1000 (Australian eastern std timezone) and 1/1/1940 >+0000 (London). > >For comparison, I guess this is true. But for correctness' sake, >recording of a date without its timezone still seems erroneous to me. > >This is a fine point, and Sam's main concern is to reduce complexity >for >implementors, always a laudable cause. I am unsure of whether the >argument about faithfulness is worth it, or whether there are other >reasons to record timezone in a pure date. > >Thoughts, anyone? > >- thomas beale > > >- >If you have any questions about using this list, >please send a message to d.lloyd at openehr.org > > -- .............................................................. Deep Thought Informatics Pty Ltd mailto:thomas at deepthought.com.au open EHR - http://www.openEHR.org Archetype Methodology - http://www.deepthought.com.au/it/archetypes.html Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html .............................................................. - If you have any questions about using this list, please send a message to d.lloyd at openehr.org