Ali Gökçen wrote:

> So, TIME is not mean only of "TIME of DAY".
> TIME is TIME and you can't resticted it as "TIME OF DAY"
> It may be "TIME of PROCCESS","TIME of IDLE","TIME of USAGE",
> Our bird, FireBird cant fly to out of ionospher yet, so
> there is no risc about "TIME of MARSDAY" format incompatibility.

Yes, TIME *is* restricted to "time of day". Or at least, its *intention*
is to be used for "time of day". Nothing more, nothing less.

> TIME works both of us, there is no need to fight about terms.

Obviously not, but it might be of interest to you (and others who might
be reading this) to note that the datatype TIME is not intended for
durations, which is what you seem to be using it for.

It might work right now, but maybe later (in later FB version or later
versions of your database acces components) TIME won't allow, for
example, a value like "39:20:35" meaning 39 hours, 20 minutes and 35
seconds (does it allow such a value now?). It might/should be restricted
to the interval 00:00:00 through 23:59:59. If you have a "time of
process" that's longer than one day, how would you store that in such a
strict TIME column?

And don't tell me that it's ok because that's just "1 day, 15 hours, 20
minutes and 35 seconds", because then you've sgtarted mixing dates into
it, and that *will* cause you problems (leap years, months of nonequal
lengths and so forth).

A DURATION on the other hand, *would* support durations of arbitrary
length, counted in days and fractions thereof.

Kjell
--
--------------------------------------
Kjell Rilbe
Adressmarknaden AM AB
E-post: kjell.rilbe@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64