[DB-SIG] DB-API Spec. 1.1a1

[Hannu Krosing]

M.-A. Lemburg wrote:

> Meaning that
> whenever you plan to do serious DB work (which will sooner
> or later deal with dates of birth), you cross the interface
> in some other way (well, maybe you're lucky and the t_time
> functions handle negative properly...). So a new date/time
> handling mechanism is due anyway.

Agreed

> Of course, dbiDate should use this new type.

It should also accept the current one (number of seconds since 1970). It can't
be too difficult ac the new date(time) type must be able to convert from/to it
anyway.

> > The mechanism of using custom types for dates and longs/blobs as
> > indicators for insert (and partially for fetch) was solved by using the
> > dbi module.
>
> I don't have a problem with using the dbi module and do see
> its relevance for those DBs which don't provide a describe API for
> prepared executes, but in this special case I think we would all
> benefit from having an extra type around -- not only for interfacing
> to DBs, but also to implement other nifty things like e.g. financial
> time calculations.
>
> > I would recommend that if you want different date/time formats, that you
> > simply implement new methods on the dbiDate instances. Better yet, just
> > relegate that work to Python layers. Bill is quite on the mark when he
> > says to avoid imposing extra work on database implementors. One single
> > format is preferable.
>
> IMHO, this should be a date object on both input and output.

The problem is backward compatibility. To what extent do we need it?

> For those interested on the date/time subject, I recommend
> the calendar FAQ:
>
>         http://www.pip.dknet.dk/~pip10160/calendar.html
>
> BTW: I'm working on a prototype for a such date type in Python.
> I'm not yet sure, but it seems that actually two types will emerge
> from it: one for fixed points in time and one to express
> time deltas.

You could check the date handling in postgres dbms (see
http://www.PostgreSQL.org)
At least the copyright terms seem to be compatible.

They are in src/backend/utils/adt/{dt|dateime|date|timestamp}.c

There are actually 2 families of date functions one t_time based and another
more generic.

They have three time types (not two as you plan) : fixed points in time
(abstime) , time deltas (reltime), and time intervals (tinterval). Of course
tinterval can be represented by just to abstimes (and then having different
variants of intervals correspond to them (for 30/360, 30/365, real/365 etc.)

Actually the financial time functions are a real can of worms and should be
wekk thought out before making it public. Later we may be even able to
persuade Guido to include the date type in core python distribution. It is the
only datatype really missing from python now.

Hannu





_______________
DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
_______________