CREATE OR REPLACE PROCEDURE test IS
datevar DATE;
int_d2s_var INTERVAL DAY TO SECOND;
int_y2m_var INTERVAL YEAR TO MONTH;
ts_var TIMESTAMP;
tswtz_var TIMESTAMP WITH TIME ZONE;
tswLtz_var TIMESTAMP WITH local TIME ZONE;
BEGIN
NULL;
END test;
/

Partial text from Metalink Note: 69028.1

Since Oracle 7 the DATE datatype is stored in a proprietary format.
DATE values are always stored in 7 bytes, excluding the length byte, within a datafile. These bytes store the century, year, month, day, hour, minute,
and second details respectively. The following is the definition of Oracle's internal DATE storage structure:

Note that the century and year components are stored in 'excess 100 format', which means that 100 must be deducted from the byte's value.
If a negative number results, then we've got a BC date at which point we take the absolute number.
Also, to avoid ever having a zero byte, 1 is added to the hour, minute and second bytes. Therefore, 1 must be detected to get the correct value.

For example, take the following date again: 17-DEC-1980 00:00:00

we would expect this date to be stored internally as follows: 119, 180, 12, 17, 01, 01, 01

Let's confirm that hypothesis by dumping the data block in question from an Oracle 8 database and examining its contents.
Let's use the "SCOTT.EMP" table for our example:

What happened? Is the information above incorrect or does the DUMP() function not handle DATE values?
No, you have to look at the "Typ=" values to understand why we are seeing these results.
The datatype returned is 13 and not 12, the external DATE datatype.
This occurs because we rely on the TO_DATE function!
External datatype 13 is an internal c-structure whose length varies depending on how the c-compiler represents the structure.
Note that the "Len=" value is 8 and not 7.
Type 13 is not a part of the published 3GL interfaces for Oracle and is used for date calculations mainly within PL/SQL operations.
Note that the same result can be seen when DUMPing the value SYSDATE.

Using deductive logic, we can derive the following storage format for type 13 data:

For AD dates, the year and base 256 modifier are stored in base 0 notation and we must add the modifier to the year to obtain the true year.
For BC dates, the year and base 256 modifier are stored in excess-255 notation. We must subtract the modifier from the year to obtain the true year.

The Julian Day number is a count of days elapsed since Greenwich mean noon on 1 January 4712 B.C. in the Julian proleptic calendar.
The Julian Date is the Julian Day number followed by the fraction of the day elapsed since the preceding noon.

All calculations made on DATE values are based on fractional days. In other words, the values of SYSDATE+1 is tomorrow's DATE at this time.
This is reminicent of the Julian Day number behavior described above.
By using the widely accepted convention of the Julian calendar that 1 day is the basic unit of time measurement, DATE calculation logic is greatly simplified.

Can contain a type description of any persistent SQL type, named or unnamed, including object types and collection types.
Only new transient types can be constructed using the ANYTYPE interfaces.

SYS.ANYDATA

See link at page bottom

SYS.ANYDATASET

Contains a description of a given type plus a set of data instances of that type.
An ANYDATASET can be persistently stored in the database or can be used as an interface parameter to communicate self-descriptive sets of data,
all of which belong to a certain type.

Media Types

Data Type Definition

Description

ORDAudio

Supports the storage of audio data

ORDDoc

Supports the storage and management of any tpe of media data, including audio, image, and video

ORDImage

Supports the storage of image data

ORDImageSignature

Supports the a compact representation of color, texture, and shape information of image data data

SI_AverageColor

Characterizes an image by its average color

SI_Color

Encapsulates color values

SI_ColorHistogram

Characterizes an image by the relative frequencies of the color exhibited by samples of the raw image

SI_FeatureList

For up to 4 image features represented by SI_AVERAGE_COLOR, SI_COLORHISTOGRAM,
SI_POSITIONAL_COLOR and SI_TEXTURE where the feature is associated with a feature weight

SI_PositionalColor

Given an image divided into rectangles, represents the feature that characterizes an image by the n by m
most significant colors of the rectangles.

SI_StilImage

Represents digital images with inherent image characteristics such as height, width, and format