[DB-SIG] Date/Time question
M.-A. Lemburg
mal@lemburg.com
Thu, 23 Mar 2000 11:27:24 +0100
hme@informatik.uni-rostock.de wrote:
>
> Hello,
>
> implementing my Ingres module, I run across the following
> implementation aspects: According to the DB API 2.0, there are methods
> for building several time/date value combinations. But the DATETIME
> object seems to represent absolute values only.
DATETIME is a type object, it doesn't refer to an object holding
date/time values. In fact, there can be different objects for
absolute date/time and relative date/time values. DATETIME and the
other type objects are only used to group the type information in
the cursor's description field in categories... e.g. mxODBC
usually maps many different type codes to one type object (that's
why the DB API spec. says that type codes in the description
field must only *compare* equal to one of the type objects -- it
allows the interface designer to create type objects which
compare equal to a class of type codes rather than just one
value). See the DBAPITypeObject class in the implementation
notes of the DB API 2.0 spec for an example.
> Is this correct? If so, has someone made a proposal for representing
> time intervals. Since Ingres supports arithmetic on absolute and
> relative time, it would be nice to have both.
Time intervals are not a SQL standard yet, AFAIK. You can still
support them in your interface, but they won't be portable
between DBs -- then again: its hard to write DB independent
code anyway..
> Most database systems, that support temporal data, have a notation of
> `now' and `today', why these values not make default parameters?
I'm not sure I understand what you mean here... why should all
date/time columns default to now() or today() ?
> As
> far as I know some Systems internally represent date/time as strings
> (Informix, Ingres). Since there's no string parameter to the date/time
> methods, conversion takes place two times.
Why ? You could implement the date/time constructors in such
a way that also accepts string on input... note that the
constructors are only meant for the input side of the interface
(and then mostly because some DBs don't provide column type
information in their APIs). The output side is not defined and
usually varies between DBs.
--
Marc-Andre Lemburg
______________________________________________________________________
Business: http://www.lemburg.com/
Python Pages: http://www.lemburg.com/python/