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

Reply via email to