Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 12 ■ DATATYPES 521
Formats
I am not going to attempt to cover all of the DATE, TIMESTAMP, and INTERVAL formats here. That
is well covered in the Oracle SQL Reference manual, which is freely available to all. A wealth of
formats is available to you, and a good understanding of what they are is vital. It is strongly
recommended that you investigate them.
I’d like to discuss what the formats do here, as there are a great many misconceptions surrounding
this topic. The formats are used for two things:
• To format the data on the way out of the database in a style that pleases you
• To tell the database how to convert an input string into a DATE, TIMESTAMP, or INTERVAL
And that is all. The common misconception I’ve observed over the years is that the format
used somehow affects what is stored on disk and how the data is actually saved. The format
has no effect at all on how the data is stored. The format is only used to convert the single binary
format used to store a DATE into a string or to convert a string into the single binary format that
is used to store a DATE. The same is true for TIMESTAMPs and INTERVALs.
My advice on formats is simply this: use them. Use them when you send a string to the
database that represents a DATE, TIMESTAMP, or INTERVAL. Do not rely on default date formats—
defaults can and probably will at some point in the future be changed by someone. If you rely
on a default date format and it changes, your application may be negatively affected. It might
raise an error back to the end user if the date cannot be converted or, worse still, it might
silently insert the wrong data. Consider the follow INSERT statement, which relies on a default
date mask:
Insert into t ( date_column ) values ( '01/02/03' );
Suppose the application was relying on a default date mask of DD/MM/YY to be in place.
That would be February 1, 2003 (assuming that code was executed after the year 2000, but
we’ll visit the implications of that in a moment). Now, say someone decides the correct and
proper date format is MM/DD/YY. All of a sudden, that previous date changes to January 2, 2003.
Or someone decides YY/MM/DD is right, and now you have February 3, 2001. In short, without a
date format to accompany that date string, there are many ways to interpret it. That INSERT
statement should be
Insert into t ( date_column ) values ( to_date( '01/02/03', 'DD/MM/YY' ) );
And if you want my opinion, it has to be
Insert into t ( date_column ) values ( to_date( '01/02/2003', 'DD/MM/YYYY' ) );
That is, it must use a four-character year. Not too long ago, our industry learned the hard
way how much time and effort was spent remedying software that attempted to “save” 2 bytes—
we seem to have lost that lesson over time. There is no excuse in the year 2005 and beyond not
to use a four-character year!
This same discussion applies to data leaving the database. If you execute SELECT DATE_
COLUMN FROM T and fetch that column into a string in your application, then you should apply
an explicit date format to it. Whatever format your application is expecting should be explicitly
applied there. Otherwise, at some point in the future when someone changes the default
date format, your application may break or behave incorrectly.
Next, let’s look at the datatypes themselves in more detail.