# new data type class proposal

**Category:** [Technical (archive)](https://discourse.openehr.org/c/technical-archive/156)
**Created:** 2002-07-12 04:27 UTC
**Views:** 9
**Replies:** 3
**URL:** https://discourse.openehr.org/t/new-data-type-class-proposal/14446

---

## Post #1 by @thomas.beale

Naturally just as we have released a version of the data types, I realised there was a class which should have been included\!

I propose to add an abstract parent of the classes DV\_DATE, DV\_TIME, DV\_DATE\_TIME, called DV\_REAL\_WORLD\_TIME\. Its only features at the moment are timezone: DV\_DURATION, and the invariant for timezone guaranteeing that it is within \-1200 \- \+1200\. The reasons I propose to add it are:

\- it captures the timezone and any other real world time characteristic we think of in one place
\- prevents the 3\-fold repetition of timezone semantics in the 3 subtypes, which was the previous situation
\- provides a useful class for implementors to hang other real world time implementation features off
\- correctly differentiates the 3 absolute types based on real world time from the 4th time type, DV\_DURATION, which does not include any real\-world time semantics
\- it makes no difference to the concrete date/time types \- the final result is still the same as in version 1\.41 of the specification\.

I could not think of a better name than "real world time"\. Other contenders are perhaps "Calendar time" \(however, calendars are really about years/months/dates\) and "Universal time", which is defined as time based on the rotiation of the earth \(previously called Greenwich mean time\)\.

A copy of the data types specification containing the change is at http://www.deepthought.com.au/health/openEHR/data_types_1_42.pdf.

Q1 \- any objections to the addition of the class?
Q2 \- any ideas for a better name?

\- thomas beale

---

## Post #2 by @Tim_Cook5

> I propose to add an abstract parent of the classes
> DV\_DATE, DV\_TIME,
> DV\_DATE\_TIME, called DV\_REAL\_WORLD\_TIME\. Its only
> features at the moment
> are time zone: DV\_DURATION, and the invariant for time zone
> guaranteeing
> that it is within \-1200 \- \+1200\.

> Q1 \- any objections to the addition of the class?

Not from here\.

> Q2 \- any ideas for a better name?

The name \(DV\_REAL\_WORLD\_TIME\) is very appropriate\.

Tim Cook
Open Paradigms, Consulting
http://www.openparadigms.com
731\.884\.4126

---

## Post #3 by @Sam

Tom

There are three data points \- the 'Universal time' \(at latitude 0 or GMT\)
and 'the offset' to calculate 'local 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 would deal with key events occuring over the period of
change to day light saving \(which could be important from a decsions support
point of view\) and the timing of events when someone is travelling and has
had treatments in different countries \- probably less important\.

Sam

---

## Post #4 by @thomas.beale

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

---


**Canonical:** https://discourse.openehr.org/t/new-data-type-class-proposal/14446
**Original content:** https://discourse.openehr.org/t/new-data-type-class-proposal/14446