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
