After thinking about this puzzle ( on and off for the last 3 days!), here is my best shot at a solution to the puzzle

I think the extra byte that VSIZE reports for SYSDATE is because of an extra byte reserved for the sign. Let me explain,

If you have ever played with dates from the BC era ( which I did not till Jurij raised this question!) you will remember that oracle displays dates from the BC era with a "-" sign before the date, e.g.

select vsize(to_date(to_char(sysdate,'mm/dd/syyyy'),'mm/dd/syyyy')) Siz,
to_char(sysdate,'mm/dd/syyyy') Dt
from dual

will give you the result
Siz --------- Dt
------------ -------------
8 ------------- 10/08/ 2001

Notice the blank space before 2001. Now doing the same to a date in the BC era, e.g. Jan 1, 4000 BC

select vsize(to_date(to_char(to_date('01/01/4000 bc','mm/dd/yyyy bc'),'mm/dd/syyyy'),'mm/dd/syyyy')) Siz,
to_char(to_date('01/01/4000 bc','mm/dd/yyyy bc'),'mm/dd/syyyy') Dt
from dual

will give you the result
Siz --------- Dt
------------ -------------
8 ---------- 01/01/-4000

Notice the "-" ve sign before 4000.

In view of the above, it is my humble opinion that the "extra" byte that VSIZE reports for SYSDATE, for DISPLAY purposes only (if you store SYSDATE into a col and do a VSIZE on that col, you will get 7 bytes - it is only while displaying that VSIZE reports 8 bytes), is because of the sign, which takes up one byte similar to storage for -ve numbers .

How about that for an explanation ?????????

-amar

P.S. Jurij, I did follow your suggestion and clicked on the link And guess what I found? "s" does not stand for scale, but assumes a value of either 0 or 1 depending on whether the number is +ve or -ve NO OFFENCE PLEASE! - amar