Louis, Implied in your post is the idea that pure dates do indeed have timezones. Do you agree that this is the case in ISO8601? If so, then I think it is better if all date/time types have a timezone.
- thomas 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) > >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. > >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