uppose you’re writing
a query to find all the invoices that were written on January 6, 2003. You know
from the control totals that 122 invoices were written that day. But when you
run this query:
SELECT * FROM Invoices
WHERE InvoiceDate = '2003-01-06'
The result set is
empty. What’s going on?
Dates and Times Are Stored in SQL Server
Before you can effectively
query date/time (or temporal) data, you have to know something about
how date/time values are stored. SQL Server supports two date/time data types:
datetime and smalldatetime. The difference between the two is the amount of
storage used. Datetime uses 8 bytes of storage, while smalldatetime uses only
4 bytes. For this reason, datetime can represent date/time values within a wider
range and with more precision than smalldatetime. These differences are summarized
in the table below.
Jan 1, 1753
Dec 31, 9999
(0.003 seconds until midnight)
To the nearest
Jan 1, 1900
Jun 6, 2079
(1 minute until midnight)
To the nearest
Both datetime and
smalldatetime represent the date and time as a value that’s equal to the number
of days in relationship to a base date. In SQL Server, that base date is midnight
on January 1, 1900. As you can see in the table, the smalldatetime type can
only represent dates from this base date on. In contrast, the datetime type
can also represent dates that are before January 1, 1900. To do that, it stores
those values as negative numbers.
To visualize how
date/time values are stored, you can think of them as consisting of two parts.
The integer portion represents the number of whole days since January 1, 1900.
The fractional portion represents the fraction of a day that’s passed since
midnight. For example, the date/time value representing noon on January 4, 1900
is stored as 3.5. In this case, 3 represents three full days since the base
date and 0.5 represents one half of a day between midnight and noon. To see
this, submit the following query:
SELECT CAST(CAST('1900-01-04 12:00' AS datetime) AS float)
The CAST function explicitly changes the data type of a value as specified.
So in this statement, the inner CAST changes the string literal '1900-01-04
12:00' to a value of data type datetime. Then, the outer CAST changes that datetime
value to a value of data type float. The final result is a floating-point representation
of the datetime value that represents noon on January 4, 1900.
So far, so good.
But the problems that crop up in querying date/time data are caused by confusion
over two fundamental facts that aren’t so obvious. First, date/time data types
are approximate numerics, not exact numerics. Second, date/time data types can’t
store a date without a time or a time without a date.
Values Are Approximate Numerics
Datetime and smalldatetime
are like the floating-point data types, float and real, in that they’re approximate
numerics. That means the value retrieved from SQL Server may be different from
the value that was originally stored. For example, if you store the expression
10/3.0 in a column of data type float, you’ll retrieve a value 3.3333330000000001.
Although this is a reasonable representation of ten thirds, it’s not exact since
it’s rounded past the 6th digit. In fact, if you add three such values
together, you get 9.9999990000000007, not 10. Of course, most programmers understand
this as a rounding error. And it’s a persistent problem for all digital computers,
not just those running SQL Server. Still, you need to be aware of it as you
code search conditions.
In contrast, when
working with exact numeric data, the value retrieved from SQL Server is exactly
the value that was originally stored. For example, if you store 10/3.0 in a
column of data type int, it’s stored as 3 and retrieved as 3. In this case,
SQL Server implicitly casts the result of the expression as a real value, 3.333333.
Then, SQL Server implicitly casts 3.333333 as an integer because it’s being
stored in a column of type int. Although this is still a rounding error, it
occurs before the value is stored, not as a result of the physical limitations
of computer storage. In other words, the error was introduced by using the wrong
data type, not by the inherent limitation of the data type itself. Since the
system always returns the same value as was stored, the data type is exact.
Now, to see how this
affects date/time values, consider the date and time value for 8:00AM on January
4, 1900. As you saw above, noon on this day is stored as 3.5, or halfway through
the fourth day. In contrast, 8:00AM is one third of the way through the day,
so its representation will be approximate. To see this for yourself, submit
the following query:
SELECT CAST(CAST('1900-01-04 08:00' AS
datetime) AS float)
You’ll get the following
But if you submit
SELECT CAST(3.3333333 AS datetime),
CAST(3.3333334 AS datetime)
you’ll get the following
As you can see, these
three values are all quite close. In fact, they’re close enough to be considered
8:00AM for most applications. However, in a search condition based on a single
value, such as:
WHERE (DTValue = '1900-01-04 08:00')
You’d only match
those rows where the stored value exactly matches 3.3333333333333335. You’ll
see how to get around this later in this article.
Without Times and Times Without Dates
SQL Server doesn’t
provide data types for storing just the date or just the time. So if you store
a date/time value without an explicit time, the fractional portion of the value
is set to zero. This represents midnight as 00:00:00. Similarly, if you store
a date/time value without an explicit date, the integer portion of the value
is set to zero. This represents the date January 1, 1900. To see this, submit
the following query:
SELECT CAST('1900-01-04' AS datetime),
CAST('10:00' AS datetime)
which returns the
Whether you can ignore
the date or the time component when you query a date/time column depends on
how the column has been designed and used.
Effect of Database Design on Querying
don’t always use date/time columns appropriately. At the time the database is
designed, each date/time column should be identified as to whether it will store
both dates and times, dates only, or times only. The designer, by using defaults,
constraints, and triggers, can enforce these rules to prevent the accidental
storage of data that are either unnecessary or not applicable.
For example, a column
in an accounts payable system for the date an invoice is received is unlikely
to need the time. In that case, the designer should plan to use the column solely
for dates and never store the time component. A trigger could be assigned to
prevent the non-integer portion of the date value from being stored when updating
the programmer is forced to work with an existing database. In this case, you
should examine the way in which the date/time values are being used before you
assume the designer did his or her job correctly.
The simplest way
to do that is to submit a query using a search condition similar to the following,
where DT is the date/time column in question:
WHERE CAST(FLOOR(CAST(DT AS float))AS datetime) = 0 OR
DT - CAST(FLOOR(CAST(DT AS float))AS datetime)
The FLOOR function returns the largest integer that is less than or equal to
the specified value. In this expression, FLOOR is applied to the floating-point
representation of the DT column. This simply strips off the fractional portion
of the number.
The first expression
returns the date (integer) portion of the value, while the second returns the
time portion. If this query returns no rows, it’s likely that the column has
been used consistently to store both dates and times, since the date is never
0 and the time is never 0.
Keep in mind, of
course, that if the above query returns rows, it doesn’t necessarily imply that
the column has been used inconsistently. If the time happens to be exactly midnight
or the date happens to be January 1, 1900, then it’ll show up in the result
set. In that case, you can test for columns with time-only or date-only data
by using either of these two queries:
WHERE TOnly <> Tonly - (CAST(FLOOR(CAST(TOnly
AS float))AS datetime))
WHERE DOnly <> CAST(FLOOR(CAST(DOnly AS
Here, TOnly and DOnly
are date/time columns that you expect contain only times or dates, respectively.
If the query returns rows, then those rows don’t contain the type of data you
kind of data are stored in the date/time columns of each table is important
for intelligent querying. If the columns are used consistently, then your job
is easier. However, even if the columns are used inconsistently, you’ll at least
know which query pitfalls to watch out for as you code your queries.