|Subject||Re: [firebird-support] Re: Hourly rate|
> > I fail to see what this has to do with the TIME datatype?The TIME datatype is valid for our little planet only.
> 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
> 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"All fine, but it will not result into a valid TIME value, EVEN if it
> 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
> May be you want to get sqrt or tangant of a TIME?
> It is not a joke, somebody may be wants 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
> >Ali, this has nothing to do with our TIME datatype, does 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" ;))Yes, but the value your are adding is not a TIME (of day) value, it's a
> > 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.
duration. This can result in a valid TIME value, or it overflows ...
> > The "check constraints" should tell you you're using a specificWhat does MxSQL has to do with it?
> > domain for your internal values. A domain that makes sense
> > for your "time value".
> > But just because some operation (eg: dividing) results in a
> > 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 meWith regards,
> 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?
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Database development questions? Check the forum!