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

[M.-A. Lemburg]

Hannu Krosing wrote:
> 
> M.-A. Lemburg wrote:
> 
> > 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.

dbiDate could be used to convert the new type into a time_t value,
raising an exception in case this doesn't work.

> > > 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?

As far as I understand the Python C API, PyFloat_AsDouble() is the
one function that C code should use to access an object as a
number. This function looks at the tp_as_number-slot and then
calls nb_float, so I guess all that's needed is to provide those
hooks returning a time_t value. So input shouldn't be a big problem.
On the output side old modules will still give you integers though --
code written for the new style interface will have to watch out for this.
Old code will expect a time_t value, so the above applies to this case
too.

> > 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.

Thanks, I'll have a look.

> 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.

You're probably right... putting too much on the agenda kills
motivation :-)

-- 
Marc-Andre Lemburg


_______________
DB-SIG  - SIG on Tabular Databases in Python

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