> > 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.

The TIME datatype is valid for our little planet only.

> > 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.

All fine, but it will not result into a valid TIME value, EVEN if it
fails within the underlying numerical range. This is what I'm trying
to say all the time -- just because you can do certain operations
on a TIME value, does not mean the result is a TIME or DATETIME
(TIMESTAMP) value. "1 day and 12 hours" is not a valid value
for the DATETIME type, for example. Yes, you can fit it in there
(on the lower level) but it isn't valid. This is what people should
understand.

> >
> > 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.

Ali, this has nothing to do with our TIME datatype, does it?

> 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.

Yes, but the value your are adding is not a TIME (of day) value, it's a
duration. This can result in a valid TIME value, or it overflows ...

> > 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.

What does MxSQL has to do with it?

> > 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?

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