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

534
CHAPTER 12 ■ DATATYPES
DUMP(TS)
-------------------------------------------------------------------------------
DUMP(TS_TZ)
-------------------------------------------------------------------------------
Typ=180 Len=11: 120,105,6,28,14,46,9,5,57,20,248
Typ=181 Len=13: 120,105,6,28,18,46,9,5,57,20,248,16,60
As you can see, upon retrieval the default TIMESTAMP format included the time zone information
(I was on East Coast US time during daylight saving time when this was executed).
TIMESTAMP WITH TIME ZONEs store the data in whatever time zone was specified when the
data was stored. The time zone becomes part of the data itself. Note how the TIMESTAMP WITH
TIME ZONE field stored ...18,46,9... for the hour, minutes, and seconds (in excess-1 notation,
so that is 17:45:08), whereas the TIMESTAMP field stored simply ...14,46,9..., which is
13:45:09—the exact time in the string we inserted. The TIMESTAMP WITH TIME ZONE had four
hours added to it, in order to store in GMT (also known as UTC) time. The trailing 2 bytes are
used upon retrieval to properly adjust the TIMESTAMP value.
It is not my intention to cover all of the nuances of time zones here in this book; that is a
topic well covered elsewhere. To that end, I’ll just point out that time zone support is more relevant
in applications today than ever before. A decade ago, applications were not nearly as
global as they are now. In the days before widespread Internet use, applications were many
times distributed and decentralized, and the time zone was implicitly based on where the
server was located. Today, with large centralized systems being used by people worldwide, the
need to track and use time zones is very relevant.
Before time zone support was built into a datatype, you had to store the DATE in one column
and the time zone information in another, and then it was the application's job to apply
functions to convert DATEs from one time zone to another. Now that is the job of the database,
and it is able to store data in multiple time zones:
ops$tkyte@ORA10G> create table t
2 ( ts1 timestamp with time zone,
3 ts2 timestamp with time zone
4 )
5 /
Table created.
ops$tkyte@ORA10G> insert into t (ts1, ts2)
2 values ( timestamp'2005-06-05 17:02:32.212 US/Eastern',
3 timestamp'2005-06-05 17:02:32.212 US/Pacific' );
1 row created.
and perform correct TIMESTAMP arithmetic on them:
ops$tkyte@ORA10G> select ts1-ts2 from t;
TS1-TS2
---------------------------------------------------------------------------
-000000000 03:00:00.000000