Tim Cook wrote:
>I certainly do not speak for Louis but have been meaning to take >time to comment on this issue. > >I wish I could support my argument with a 'solid' example. :-) >All I can say is that, I can imagine an instance (and it only takes >one to break a model) where a person is traveling from Los Angles to >Sydney and has just had an injection of some type before leaving >LA. They get to Sydney and seem to be having a reaction and are >taken to the Emergency Dept. Since we have this really cool world >wide accessible electronic health record, the staff gains proper >authority and reviews the patient's treatment before leaving LA. Do >they instantly know the time difference between LA and Sydney? > ok - two things - 1. the time in this instance will have been recorded as a date/time - i.e. with time as well (not just a date) 2. if we do have timezone info in date/times, I think we are covered - assuming of course that the correct timezone values are written into the data items in each place But I have to say that the kind of scenario you mention was also what I was thinking of. But then Sam brought up the point that if you were indeed jsut comparing two dates (no time info, but with timezone info) then the timezone info doesn't help you, since any pure date has a buil-in 24h window of "error" . For the operation of comparison, I guess this is true. But for faihfulness of recording, I think we should have timezone on all date/times anyway, and one argument at least is that if you are doing it in the software for DV_DATE_TIME, DV_TIME, DV_PARTIAL_TIME, etc then it's easier just to do it for DV_DATE as well and be done with it. In any case, when I or some kind soul gets round to it, we will formally add the semantics of comparison of all date/time types. >There must be a universal reference point if we are to envision >world wide access to a single record (virtual or physical) for care >and health tracking. > so I think UTC expressed in one of the ISO 8601 formats fits the bill. Now, just looking at the explanatory pages at http://www.mcs.vuw.ac.nz/technical/software/SGML/doc/iso8601/ISO8601.html and http://www.cl.cam.ac.uk/~mgk25/iso-time.html, I cannot actually see whether ISO8601 supports timezones on pure dates or not. Can anyone verify this for us? >Given the fact that there are known duplicates in the abbreviations >used in timezones the offset to UTC should be used as a five >character string; -0600 or +1000 etc. > I think you are saying we should nail it down to be one of the allowed ISO8601 formats. I think I would agree. And now that I think about it, the timezone limits whcih I set to be -1200 to +1200 are probably wrong - the customary way to do it is to go positive till you hit the dateline which is sometime after NZ or fiji, so I guess about +1400, and the max the other way must be -1000. Anyone got a firm answer on this? > >This also accomodates the various DST rollovers also. > My understanding of this, is that you always record the timezone with the DST included. Your software also has to know the fixed timezone map of the world, and if it sees a +1100 where it expected a +1000 (e..g Sydney during daylight savings) it knows that DST is on at the moment in that place. - thomas beale -- .............................................................. 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
