Portable SQL to compute a date difference in seconds???

#11

Ed Prochak wrote:

Quote:

On May 15, 7:01 pm, Lee Fesperman <first... (AT) ix (DOT) netcom.com> wrote:
Gints Plivna wrote:
An variation on the comment from Gints:
Time for the DBMS vendors to understand that their lack of
standardisation is costing people a lot of time and effort.

There are many cars around an you cannot simply get engine from
Ferrari and put it into Trabant. Each model is predicted for different
needs and resources, each is manufactured by different company,
developed by different people thinking differently, each have his own
history, they'll never be equal.
And that's why we have alternatives, that's why the life is
interesting

Disagree. A better analogy might be switching cars rather than
engines. Here the user experience is easier --- you can probably jump
in most cars and start driving right away. Unfortunately, humans are
much more flexible than software ;^)

Yes, the analogy is better but the same issues exist.

Ever get a rental car where the Lights switch was in a different
place? Wipers? Two basic safety features are not standard on cars.
Getting a standard transmission is also a significant challenge for
some drivers, just as changing the locking model of the DB engine is a
challenge to some programmers. And it takes an analogous period of
time to adjust from one car to another as it does from one DBMS to
another. Unfortunately, it is the flexibility of humans doing the
programming that continues to allow this situation to exist.

I've driven many rental cars. Wiper switches, light switches and gas
caps are minor nuisances, resolved in a few moments. They hardly
compare to the effort in software development related to switching
DBMSs. Standard vs. automatic transmissions are a bigger problem (I
made sure my offspring could drive 'stick'). I'm not sure it fits the
analogy.

Quote:

Also for DBMSs, a standard (ANSI SQL) exists ... that is willfully
ignored by vendors. In addition, there is the Relational Model (RM),
mostly ignored by vendors too. It's RM where tuning is a problem.
Improper, arcane optimization severely impacts relational power.

Les,
Does the SQL standard really specify Date and Time processing? From my
understanding (second hand since I have not read the actual standards
documents) is that Date and Time data types are purposely vague. This
allows vendors with widely different implementations to claim
compliance. This doesn't help the original person, but it is how it
is.

Actually, date/time is very specific and quite complete in Standard
SQL. There are DATE, TIME and TIMESTAMP datatypes with fractional
seconds and optional timezone (TIME & TIMESTAMP). Comparison, cast and
arthimetic operators take date/time values. For instance, subtracting
two date/time values yields an INTERVAL value. INTERVAL datatypes can
be year-month or day-time with all variants in between -- day-hour,
hour-second.

BTW, my name is Lee, Ed...

Quote:

I'm actually dealing with the date time issue right now, since I work
with both UNIFY Dataserver (Separate DATE and TIME data types) and
ORACLE (DATE data type includes time) and have to move data between
the two. It can get tedious, but we deal with it.

Date/time and interval datatypes and operators are an area where most
SQL DBMSs are non-compliant. See http://www.firstsql.com/tutor6.htm#type
on SQL96 DATE/TIME/TIMESTAMP/INTERVAL datatypes and http://www.firstsql.com/tutor3.htm#exp
on arithmetic expressions and literals.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Portable SQL to compute a date difference in seconds???

comp.databases comp.databases

Re: Portable SQL to compute a date difference in seconds??? - 05-18-2007 , 03:22 AM