Sam Heard wrote:
>Tom > >There are three data points - the 'Universal time' (at latitude 0 or GMT) >and 'the offset' to calculate 'local time'. > What I have proposed as "world time" is really of course "universal time", but I didn't call it that because people tend to think of that phrase as meaning an actual timeline - it sounds a bit strange as a parent class for DATE, DATE_TIME and TIME. Anyway, at David Lloyd's suggestion, I have shortened it to DV_WORLD_TIME. >It seems to me that the EHR will probably be based on local time - and >recording the offset once per the transaction would give the absolute time >of an event. > This is how we did it in GEHR, and according to good data modelling, probably how you would do it. The main reasons to add the timezone to each date/time is that it is easier for computation - any query, API call, EHR extract which grabs the date/time automatically gets the timezone offset; no need to hunt around in the Transaction header. > This would deal with key events occuring over the period of >change to day light saving (which could be important from a decsions support > My current understanding of daylight savings is that the place it applies to e.g. Pacific North America, Central Europe etc, moves into a different timezone for a certain number of months. THis means that timezone records the effect of daylight savings as well. >point of view) and the timing of events when someone is travelling and has >had treatments in different countries - probably less important. > The VHA has this as one of their use cases - people being treated on board planes or other transport, or at either end. - thomas beale - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
