From a technical point of view there are several aspects to be considered. First we need to distinguish between the time an object was created or updated in the database (transaction time) and the times the object exists in reality (valid time). The terminology used here is confusing because of the variety of terms in use. Table 2.2 lists some of the frequently used terms and synonyms. Most authors make use of transaction time, but are concentrating on event-based models where only the changes are recorded and stay valid until another change occurs. Aside from these two representations, it is always possible to implement a so called user-defined time in databases by storing these values in standard (e.g. integer or floating point) fields (user-defined time). But this is not the approach needed here. The aim is to create a universal representation of temporal aspects in databases.
| Author | Transaction time | Event time | Valid time |
| Lum et al. (1984) | physical time | logical time | |
| Lum et al. (1984) | database time | world time | |
| Snodgrass and Ahn (1985) | transaction time | valid time | |
| Kemp and Kowalczyk (1994) | database time | world time | |
| Yearsley et al. (1994) | database time | event time |
Newer publications, especially those using an object-oriented approach, accept the need for valid time defined as the duration for which an object exists.
Recent discussions on temporal representation propose the creation of
instant, interval and period data types with both variable granularity and
uncertainty (Kemp and Kowalczyk, 1994). An instant type represents a single
point in time (e.g. 1.1.1990 01:00:00h) whereas the period type is
defined by two instants. The interval type is an unanchored duration
of time. Handling unknown or undefined instants is done using special
values representing for example infinity (-
, ). It also would
be possible to use a 'time ray' type to represent events
(instants) that are finished (or started) without a defined start
(end).
Examples for applications of these representational aspects of time can be found in Yearsley and Worboys (1995); Bagg and Ryan (1997).
How is time really implemented in today's computer systems? Traditionally most software support some date type. It is maintained as a number of days passed since a specific date (see table 2.1). A (day-)time field was often neglected and in some systems it is still missing (e.g. ESRI's Arc/Info). In several systems, for example SQL, the SAS system and the Oracle8 system, a DateTime field was introduced holding both date and time in a single field. In addition Oracle8 also knows about the Julian date. In the Unix environment a similar time structure is defined, which counts the number of seconds since 00:00:00 of January 1, 1970. It has functions to access the contents of the time structure as year, month, day, hour, minute, second and also contains a flag for the daylight saving time. Aside from this time structure Unix also keeps track of the current time zone which contains the difference between UTC and the local time, although this is done at the system level and not at the application level. The last two fields (daylight time, time zone) are seldom seen in standard applications.
It is clear from these few examples that there is a variety of implementations of time in today's computer systems. Most of them only cover a fraction of the information needed to reflect the full temporal information needed when handling geographical data spread all over the earth.