the row representing that assertion will cease to be asserted on
that date even if no correcting assertion is supplied to replace it.
The last reason an assertion end date may be changed is to
lock an assertion which has been updated or deleted by a
deferred transaction, until the resulting deferred assertion
becomes current. We will have more to say about deferred trans-
actions, deferred assertions and locking in Chapter 13.
Now() and UTC
Keeping our notation DBMS agnostic, and keeping the clock
tick granularity generic, we will refer to the current moment, to
right now, as Now().
7
SQL Server may use getdate(), and DB2
may use Current Timestamp or Current Date. Depending on our
clock tick duration, we might need to use a date formatting func-
tion to set the current granularity. In our examples, we generally
use one month as our clock tick granularity. However for our
purposes, Now() can take on values at whatever level of granular-
ity we choose to use, including day, second or microsecond.
Now() is usually assumed to represent the current moment by
us
ing local time.
But local time may change because of entering
or leaving Daylight Savings Time. And another issue is time zone.
At any one time, data about to update a database may exist in a
different time zone than the database itself. Users about to retrieve
data from a database may exist in a different time zone than the
database itself. And, of course, federated queries may attempt to
join data from databases located in different time zones.
So the data values returned by Now() can change for reasons
other than the passage of time. Daylight Savings Time can

itself. This is because most optimizers treat functions that
appear in predicates as non-indexable. For example, in DB2,
we should write:
SET :my-cut ¼ TIMESTAMP(:my-local-time-value) - CURRENT
TIMEZONE
SELECT .....FROM .....
WHERE oid ¼ 55
AND asr_beg_dt <¼ :my-cut
AND asr_end_dt > :my-cut
rather than
SELECT .....FROM .....
WHERE oid ¼ 55
AND asr_beg_dt <¼
TIMESTAMP(:my-local-time-value) - CURRENT TIMEZONE
AND.....
However, if these functions are used for display purposes, then
there is no reason to exclude them from the queries. For example:
SELECT asr_beg_dt þ CURRENT TIMEZONE AS my_local_asr_beg_dt . .
...FROM.....
It would also be useful to add alternate columns for the tem-
poral dates in our views that have the translation to local time
performed already.
The Very Concept of Bi-Temporality
Business IT professionals were using tables with both an
effective date and a physical row create date by the early 90s.
9
But they were doing so with apparently no knowledge of
9
Or timestamps, or other datatypes. We remind the reader that, throughout this book,
we use the date datatype for all temporal columns, and a first of the month value for

rality in exactly the same way. The difference lies primarily in the
second of the two temporal dimensions, what computer scientists
call “transaction time” and what we call “assertion time”. While a
transaction begin date always indicates when a row is physically
inserted into a table, an assertion begin date indicates when we
are first willing to assert, or claim, that a row is a true statement
about the object it represents, during that row’s effective (valid)
time period, and also that the quality of the row’s data is good
enough to base business decisions on.
In the standard temporal model, the beginning of a transaction
time period is the date on which the row is created. Obviously,
once the row is created, that date cannot be changed. But in the
Asserted Versioning temporal model, an assertion time period
begins either on the date a row is created, or on a later date.
Because an assertion begin date is not necessarily the same
as the date on which its row is physically created, Asserted
Versioning needs, in addition to the pair of dates that define this
time period, an additional date which is the physical creation
date of each row. That date serves as an audit trail, and as a
means of reconstructing a table as it physically existed at any
past point in time.
64
Chapter 3 THE ORIGINS OF ASSERTED VERSIONING: COMPUTER SCIENCE RESEARCH
What are these rows with future assertion begin dates? To
take a single example, they might be rows for which we have
some of the business data, but not all of it, rows which are in
the process of being made ready “for prime time”. These
rows—which may be assertions about past, present or future
versions—are not yet ready, we will say, to become part of the
production data in the table, not yet ready to become rows that

italicized; when two time periods are identical, they do not
have a distinct inverse. Thus, this taxonomy specifies 13 leaf-
node relationships which are, in fact, precisely the 13 Allen
relationships.
The names of the Allen relationships are standard, and have
been since Allen wrote his seminal article in 1983. But those
names, and the names of the higher-level nodes in our own tax-
onomy of the Allen relationships, are also expressions in
Chapter 3 THE ORIGINS OF ASSERTED VERSIONING: COMPUTER SCIENCE RESEARCH
65
ordinary language. In order to distinguish between the ordinary
language and the technical uses of these terms, we will include
the names of Allen relationships and our other taxonomy nodes
in brackets when we are discussing them. We will also underline
the non-leaf node relationships in the taxonomy, to emphasize
that they are relationships we have defined, and are not one of
the Allen relationships.
In the following discussion, the first time period in a pair of
them is the one that is either earlier than the other, or not longer
than the other.
Given two time periods on a common timeline, either they
have at least one clock tick in common or they do not. If they
do, we will say that they [
intersect] one another. If they do not,
we will say that they [
exclude] one another.
If there is an [
intersects] relationship between two time per-
iods, then either one [
fills] the other or each [overlaps] the other.

Aligns
|-----|
|------------|
|-----|
|-----------|
Figure 3.4 The Asserted Versioning Allen Relationship Taxonomy.
66
Chapter 3 THE ORIGINS OF ASSERTED VERSIONING: COMPUTER SCIENCE RESEARCH
other does not have, as well as having at least one clock tick that
the other does have.
If two time periods [
exclude] one another, then they do not
share any clock ticks, and they are either non-contiguous or con-
tiguous. If there is at least one clock tick between them, they are
non-contiguous and we say that one is [before] the other. Other-
wise they are contiguous and we say that one [meets] the other.
If one time period [
fills] the other, then either they are [equal],
or one [
occupies] the other. If they are [equal], then neither has a
clock tick that the other does not have. If one [
occupies] the
other, then all the clock ticks in the occupying time period are
also in the occupied time period, but not vice versa.
If one time period [
occupies] the other, then either they share
an [
aligns] relationship, or one occurs [during] the other. If they
are aligned, then they either start on the same clock tick or end
on the same clock tick, and we say that one either [starts] or

(i) The [
intersects] relationship is important because for a tem-
poral insert transaction to be valid, its effective time period
cannot intersect that of any episode for the same object
which is already in the target table. By the same token, for
Chapter 3 THE ORIGINS OF ASSERTED VERSIONING: COMPUTER SCIENCE RESEARCH
67
a temporal update or delete transaction to be valid, the tar-
get table must already contain at least one episode for the
same object whose effective time period does [
intersect]
the time period designated by the transaction.
(ii) The [
fills] relationship is important because violations of
the temporal analog of referential integrity always involve
the failure of a child time period to [
fill] a parent time
period. We will be frequently discussing this relationship
from the parent side, and we would like to avoid having to
say things like “. . . . . failure of a parent time period to be
filled by a child time period”. So we will use the term
“includes” as a synonym for “is filled by”, i.e. as a synonym
for [
fills
À1
]. Now we can say “. . . . . failure of a parent time
period to include a child time period”.
(iii) The [before] relationship is important because it
distinguishes episodes from one another. Every episode of
an object is non-contiguous with every other episode of

the other by the Y-axis.
Another approach is to manage each of the two temporal
dimensions separately. One reason for taking this approach is that,
for the standard temporal model, the two temporal dimensions
behave differently. Specifically, for the standard model, transac-
tion time always moves forwards, whereas valid time can move
forwards or backwards. This means that a bi-temporal row can
be inserted into a table proactively in valid time, but can never
be inserted into a table proactively in transaction time.
Asserted Versioning, as we have already pointed out, supports
both forwards and backwards movement in both temporal
dimensions. So for Asserted Versioning, there is no difference
in behavior which would justify separating the two temporal
dimensions for indexing purposes. Specifically, Asserted
Versioning supports both proactive (future-dated) versions and
proactive assertions (i.e. deferred assertions) and also both retro-
active versions and an approval transaction which can move
deferred assertions backwards in time, but not prior to Now().
In Chapter 15, we will describe certain indexing strategies that
will improve performance using today’s DBMS index designs.
Temporal Extensions to SQL
Following [2000, Snodgrass], we will refer to a future release
of the SQL language that will contain temporal extensions as
SQL3. A more detailed discussion may be found in that book,
although we should note that the book is, at the time of publica-
tion of this book, 10 years old.
Temporal Upward Compatibility
One issue related to changes in the SQL standard is temporal
upward compatibility. In describing SQL3, Snodgrass states that
“(t)emporal upward compatibility at its core says this: ‘Take an