--- In firebird-support@yahoogroups.com, "Martijn Tonies"
<m.tonies@u...> wrote:

>
> I fail to see what this has to do with the TIME datatype?

This was proof of TIME is not meaning of real-time.
There is no real-time. Using of meridian is not must.
Lets make a techo fantasy..
You are going to Mars' office department of Upscene.
What TIME system will you use and store to TIME field in there?
Will you use mars merdians?(i am sure there must be a greenwich of
GB)
Or are you say: hey TIME type is incompatable for here, we need a
new datatype for Mars.

>
> TIME - the datatype - is NOT a numeric value, it's "time of day"

as Helen

> explained. How it is stored internally does not mean

that "dividing" a TIME

> will give you a TIME as a result, although you can assign the

result to the

> internal storage mechanism of TIME.

I never said, you may be want to divide a time value. It was your
theory.
May be you want to get sqrt or tangant of a TIME?
It is not a joke, somebody may be wants it.

>
> 08:00 divided by 2 does not give you "time of day" 04:00 ... Yes,

you can

> assign it internally, on the low-level of "numeric value", but

it's not

> right.
>

You can divide a TIME field if you want, but you should to convert it
to a computable numeric value.
what happens when anybody want to divide a TIME value for example:
'20:00' / 0.5 ?
You cant caluculate this in a TIME format, so you need a another
large numeric datatype.
After calculation, you can get result as DAYS + TIME.
You can create a new datatype to handle such type values of course.
But it is not a must.

For example you have some industrial machines,
they needs n days and m hours for their proccesses.
And you need to handle-store-manage their timings with FB.

>
> All this has nothing to do with maths on TIME.

it does.

hours*3600+minutes*60+seconds = TIME as seconds.
you can add milliseconds of course. (1.000/milliseconds)

>
> There are different rules. The concept of TIME is such that
> TIME cannot be 25:00 ... I said this before and this still holds.
>

Martijn, TIME may be more than 25:00 on jupiter if you
accept it as an turning speed of any planet, front of sun.

Thats why Jim says "Not a rocket technology" ;))

>
> Oh brilliant. Then you should know that there's no concept of
> "time" that holds 25 hours. That's a duration/interval etc...

I never said this. remember my solution for Arnoldo.
It was a numeric calculation step by step and rebuild of duration
days and TIME from result value.
You can add this values to any TIMESTAMP to find out when will the
task finish.

>
> The "check constraints" should tell you you're using a specific
> domain for your internal values. A domain that makes sense
> for your "time value".
>
> But just because some operation (eg: dividing) results in a

numerical

> value that is inside your constraints does NOT mean it's a valid
> result on the conceptual level.

Can you proof my any fault about my calculation?
I didnt try to divide a TIME type.
I didnt try to any calculaton on TIME type.

Are you saying my problem solving is wrong???
I have no any complaint about FB, it was you.
I have never seen your new datatype suggestion in any RDBMS i used.
I have no idea about MxSQL, may be there.

>
> Now, I asked you before: if you think I'm wrong, then proof me

wrong.

>

No, you are not wrong, i can not proof it.
It should be fine, if there are some more builtin date-time
calculation functions in FB.
We shouldn't to force users to do low level calculations.
I answered Arnaldo because of it, i didnt take it as a joke.
But you know there is alot of restrictions in any system.
For example you can not write a query inside its trigger for a table
in ORACLE. Comic! ( remember Lester's trigger a few days ago)
Also you can not select from SPs. You need some ugly-slowest ways to
simulate it. Computed fields? huh what is it?

Regards.
Ali