Lester,

> My point was that you can just treat timestamps as numbers
> when you want to use them like that.

got your point (at least I think so).
Still I think it's flawed. You can add a number to a timestamp to obtain
a timestamp, you can subtract two timestamps and get a number (a
duration), but "converting" a time stamp to a number just does not make
sense because a timestamp is not a number from a semantical POV.

> > Your select will give you a result of the type of TABLE.FIELD1; if it's
> > a date/time/timestamp you don't see the conversion of it to a string,
> > just the only reasonable printed representation for it (in no case
> > should you see 3045.533).
>
> The remaining problem is that the reasonable printed
> representation may not be what is wanted. If you are doing
> calculations on the dates or times, you want the numbers.

If you are doing calculations you actually *get* the numbers. But this
does not imply that the sources of your calculations (the timestamp
values) are themselves numbers. I don't know how to express it more
clearly.

Perhaps we are just saying the same thing in two different ways...

> The only 'mistake' I made was I did not ask - "What is the
> correct way to get the number when that is what we actually
> want?"

Never felt the need to even assume a timestamp is a number (or a
TDateTime is a Double in Delphi). When I need to store it, I store a
timestamp, when I need to do calculations, I do them as the semantical
rules for that datatype allow me to.
That's why the original question rang a bell to me: IMHO if the
questioner needed to know the internal representation (the number) of a
timestamp, he was approaching something wrong. Which is indeed the case,
because to know the difference between two dates you don't need to know
how they are represented; they could well be strings, floating point
values or whatever, as long as date2 - date1 returns a number.
Ciao
--
____
_/\/ando