>  The updated spec (1.1a8) is at:
> 
>          http://starship.skyport.net/~lemburg/DatabaseAPI-1.1.html
> 
>  I've folded dbi into the module interface and added constructors
>  Date, Time and Timestamp (as well as corresponding type codes).
>  Note that only the constructor names are defined -- not whether
>  the result from calling these specifies a certain type or instance.
> 
>  Hmm. Maybe it'll be 2.0 after all... punting dbi, new
>  interfaces, different semantics...
> 



reading through your 1.1a8 spec I have the following remarks hoping to offer in some conveni
ence functions with the python time module:



Where we have:
          Date(year,month,day)
               This function constructs an object holding a date value.

          Time(hour,minute,second)
               This function constructs an object holding a time value.

          Timestamp(year,month,day,hour,minute,second)
               This function constructs an object holding a time stamp value.


Add:
TimeStamp (string[, format])
*** (time.strptime compatible)
               This function constructs an object holding a time stamp value.
    Parse a string representing a time according to a format. The format parameter uses the 
same directives as those used by time.strptime(); it defaults to
"%a %b %d %H:%M:%S %Y" which matches the formatting returned by ctime().

Add:
TimeStamp (tuple)
*** (time.mktime or time.asctime compatible)
               This function constructs an object holding a time stamp value.
    Its argument is the full 9-tuple (since the dst flag is needed -- pass -1 as the dst fla
g if it is unknown) which expresses the time in local time, not
UTC.

Add:
gmtime (TimeStamp)
*** (time.gmtime identical return)
    Convert a TimeStamp to a time tuple in UTC in which the dst flag is always zero.

Add:
localtime (TimeStamp)
*** (time.localtime identical return)
     Converts to local time. The dst flag is set to 1 when DST applies to the given time.

Retract:
***
mxTime as an inherent piece of db-sig discussion.

Use mxTime as is necesary for implemenation purposes, but keep the python learning curve sli
m and to the point.

mxTime's presence should be escalated to the python kernel concerns (we want better time), h
owever, this db-sig has become tangental and worrisome with no
substantial core interface adherence in it's 1.0 incarnation.

while DB-sig seems to have made a great case for a more reliable time library, that thread s
hould be processed in a general-python-improvement sig.

I see this SIG moving very swiftly towards an idealistic pinnacle.  I would like to contribu
te my 2 cents worth, I want a simple and direct DB interface
class to adhere to.  I want to be able to teach a neophyte DBA who just learned SQL everythi
ng *except* OO syntactic sugar.  I want their experience with
maintaining my python application to be as simple as looking up the python core api and modu
les and adding a new function call.

furthermore, I want to see python have the full benefit of mxTime as a default transparent u
pgrade, and would love to help make this a reality.

I'm doing significant amounts of multi-dbms python work presently and am in fact writing my 
own middle-interface drivers in lack of standardized
conventions.  I would love to help push through something simple, solid, perhaps not idealis
tic, but at least published and distributed with working
implementation rsn.

Thanks
-jim