Suppose 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?
How 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.
|
Type |
Minimum |
Maximum |
Precision |
|
datetime |
Jan 1, 1753 |
Dec 31, 9999 |
To the nearest |
|
smalldatetime |
Jan 1, 1900 |
Jun 6, 2079 |
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:
Note: 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.
SELECT CAST(CAST(‘1900-01-04 12:00’ AS datetime) AS float)
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.
Date/Time 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 result:
3.3333333333333335
But if you submit this query:
SELECT CAST(3.3333333 AS datetime), CAST(3.3333334 AS datetime)
you’ll get the following results:
1900-01-04 07:59:59.997 1900-01-04 08:00:00.003
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.
Dates 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 following result:
1900-01-04 00:00:00.000 1900-01-01 10:00:00.000
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.