Ali,

> > The TIME datatype is valid for our little planet only.
>
> Did our little planets carbon copy peoples decide about what is the
> TIME?
> :P

There's a difference - as Helen tried to explain to you - between
the word "time" and the datatype TIME.

> > 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.
> >
>
> Martijn, don't be so conservative about relative terms.
> As i said before there is alot of calendar and time types.
> Look at to the sand clock of windows. ;)
>
>
> You can not store any historical events in a FB db why?
> because there was a idiotic HW restriction when Jim create IB, or
> groton database or RDB/LN or datatrieve.

No there wasn't. They made a specific decision on how to
handle a certain domain. If the requirement was:
handle dates from -20.000 up til 20.000, then the solution
would have been different.

> Is is that mean, there was no time in this planet before 1857?
>
> Timestamp is a info about calendar plus time offset(meridian offset)
>
> It must not to be day offset, it may be any evets offset.
> Because there is no real-time; time is not real.
> Time is a numeric offset value displaying in a human interpretable
> format.

That's not the issue.

> There was sailors when our planet time system created.
> They need to parse this planet to goal of old GPS.
>
> What will you do in Mars, will you use Mars's calendar system?
> And how will you syncronize your life with Mars?

That's not the issue.

> This is not a fantasy even today. There is alot of spaceships in
> cosmos, which time system they will use?

I don't care, that's not the issue.

> > Ali, this has nothing to do with our TIME datatype, does it?
>
> TIME is mean of offset value starts from any another known offset
> position.
> If u want to store only local clock times to it, it is fine with me.
> But don't want to do this from other people.
> As a programmer, i have been using my low level (out of HW/OS)
> calculation in alot of offical forms, invoices for a long time,
> i havent seen any problem, didn't get any compliant. I can
> calculate all daynames, weeks, from 1.1.1
> I havent get any project to store stone age till now,
> if i, i can this too.

That's not the issue.

> > What does MxSQL has to do with it?
> >
>
> Because i have no idea about time related functions and datatypes
> of MSSQL or MySQL.

They why do you bring them into this conversation?

> If they solved our little planet peoples TIME problems we
> should to stole it from them for the first time. ;)

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?

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