> > You keep on talking about "time" in real life and how this has been
> > agreed upon (or not agreed upon) etc...
> >
> > I keep on talking about the TIME datatype, which is what the issue
> > is about. Don't you see the difference?
> >
>
> TIME datatype is work as designed and fits requirements as neeeded,
> Martijn.
> It keeps any duration from first second to last second in its limits.
> If 24H fits your work, you can use it.
> You may not want to use TIMESTAMP if your TIME infos don't want/care
> the calendar system.
> TIME datatype works perfectly for me.
> I can't say this for TIMESTAMP, because it stores
> values with some arbitrary restrictions, calendar is a playable info,
> it works irregular.
>
> Finally, i didn't understand your problem with TIME datatype.

I have none. Never said I did.

I only made a remark about the TIME datatype that when you are
applying math to it (eg: substracting one TIME from another), you
don't always get a TIME as the result.

Then you started about time being just a numerical value and you can
do anything you like with it.

Which is wrong on the conceptual level. A TIME - TIME doesn't
result in a TIME value. Period. Yes, it fits the internal implementation,
but it's still not a TIME value.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com