SQL> create table dates (d date); Table created. SQL> insert into dates values (to_date('18/APR/2002 15:06:00', 'DD/MON/YYYY HH24:MI:SS')); 1 row created. SQL> select dump(d) from dates; DUMP(D) -------------------------------------------------------------------------------- Typ=12 Len=7: 120,102,4,18,16,7,1
The first two bytes represent the century and year respectively. Each of these bytes have an offset of 100 to allow for the negative centuries and years required for BC dates. For example, the byte pair 96,8 would represent the year 492 BC (the year of the battle of Marathon). The 3rd and 4th bytes represent the month and the day of that month respectively. The last three bytes represent the hour, minute, and second. Each of these time bytes have an offset of 1 to ensure that dates can never contain null bytes. So the contents of the seven bytes are as follows.
byte 1: century + 100
byte 2: year + 100
byte 3: month
byte 4: day of month
byte 5: hour + 1
byte 6: minute + 1
byte 7: second + 1
SQL> select dump(to_date('18/APR/2002 15:06:00', 'DD/MON/YYYY HH24:MI:SS')) from dual;
DUMP(TO_DATE('18/APR/200215:06:00
---------------------------------
Typ=13 Len=8: 210,7,4,18,15,6,0,0
Here the datatype number is 13, instead of 12. The memory structure has been padded to a 4-byte boundary. The time bytes do not have any offset. And the century and year are represented as a single signed two byte number. Because this dump was taken on a machine with a little-endian architecture, the bytes are reversed and should be read as 7,210 or 0x7D2, which is decimal 2002. The corresponding bytes for 492 BC would be 20,254. That reverses to 254,20 or 0xFE14, which is -492 in two's complement notation. These details are of course platform specific.
© Ixora Pty Ltd. All rights reserved.
19-Apr-2002 |
|