05.11.2015 Views

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

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

536<br />

CHAPTER 12 ■ DATATYPES<br />

We can see that in this case, three totally different date/time representations were stored:<br />

• DT: This column stored the date/time 5-JUN-2005 17:02:32. The time zone <strong>and</strong> fractional<br />

seconds are lost because we used the DATE type. No time zone conversions were<br />

performed at all. We stored the exact date/time inserted, but lost the time zone.<br />

• TS1: This column preserved the TIME ZONE information <strong>and</strong> was normalized to be in<br />

UTC with respect to that TIME ZONE. The inserted TIMESTAMP value was in the US/Pacific<br />

time zone, which at the time of this writing was seven hours off UTC. Therefore, the<br />

stored date/time was 6-JUN-2005 00:02:32.212. It advanced our input time by seven<br />

hours to make it UTC time, <strong>and</strong> it saved the time zone US/Pacific as the last 2 bytes so<br />

this data can be properly interpreted later.<br />

• TS2: This column is assumed to be in the database’s time zone, which is US/Eastern.<br />

Now, 17:02:32 US/Pacific is 20:02:32 US/Eastern, so that is what was stored in the bytes<br />

...21,3,33... (excess-1 notation; remember to subtract 1).<br />

Since the TS1 column preserved the original time zone in the last 2 bytes, we’ll see the following<br />

upon retrieval:<br />

ops$tkyte@ORA10G> select ts1, ts2 from t;<br />

TS1<br />

----------------------------------------<br />

TS2<br />

----------------------------------------<br />

05-JUN-05 05.02.32.212000 PM US/PACIFIC<br />

05-JUN-05 08.02.32.212000 PM<br />

The database would be able to show that information, but the TS2 column with the LOCAL<br />

TIME ZONE (the time zone of the database) shows the time in the database’s time zone, which is<br />

the assumed time zone for that column (<strong>and</strong>, in fact, all columns in this database with the<br />

LOCAL TIME ZONE). My database was in the US/Eastern time zone, so 17:02:32 US/Pacific on<br />

the way in is now displayed as 8:00 pm East Coast time on the way out.<br />

The TIMESTAMP WITH LOCAL TIME ZONE provides sufficient support for most applications,<br />

if you need not remember the source time zone, but only need a datatype that provides consistent<br />

worldwide h<strong>and</strong>ling of date/time types. Additionally, the TIMESTAMP(0) WITH LOCAL ➥<br />

TIMEZONE provides you the equivalent of a DATE type with time zone support; it consumes<br />

7 bytes of storage <strong>and</strong> allows you to store dates “normalized” in UTC form.<br />

One caveat with regard to the TIMESTAMP WITH LOCAL TIME ZONE type is that once you create<br />

tables with this column, you will find your database’s time zone is “frozen,” <strong>and</strong> you will<br />

not be able to change it:<br />

ops$tkyte@ORA10G> alter database set time_zone = 'PST';<br />

alter database set time_zone = 'PST'<br />

*<br />

ERROR at line 1:<br />

ORA-30079: cannot alter database timezone when database has<br />

TIMESTAMP WITH LOCAL TIME ZONE columns

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!