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

[M.-A. Lemburg]

Bill Tutt wrote:
> 
> The "best way" for date/time formats is easy.. DON'T
> The reason you don't want to do this is because it imposes an uncessary
> requirement on the code that works with the database i.e. dealing with
> different date formats.. Thats just silly.
> 
> The specifics for any date/time format is quite easy...
> 
> 1) Data its storing i.e. (year, month, day, hour, minute, second, billionths
> of a second as an integer)
> 2) A method to format the date
>         (perferabbly using a strftime() format string, with an extension for
> parts of the data type that strftime() doesn't
>         deal with)
> 3) A method to parse a date given a strftime() like format string.
> #'s 2 & 3 should be preferrably written in C

Is this possible ? Take months for example: these can are formatted
in the current locale's writing by strftime(), so we would have to
adapt these too somehow. But to start we could skip these
formats for the time being. I'm currently using a function which
knows about these formats:
	- 1.1.90, 01.01.90, 1.1.1990 (date only, time defaults to 0:00:00)
	- 1.1. (current year is appended, 0:00:00)
	- 1.1.90 14:00
	- 14:00 (today is used as date)
I've never run into a situation where I want to parse input of the
form 'Friday, Oct. 13'. This is just much to error prone (real users
even have problems with the above...).

> Additional code that will need to be written will be some code to convert a
> C double into this date type,
> as well as conver this date type into a double.
> The OLE DateTime type uses a double to represent dates.

All this sounds like there is a need for a new DateTime-type
in general -- which is a good idea (has anyone ever tried to
handle historic dates in Python?). But that type should then become
part of the Python distribution and thus needs to be well cooked.

There was some discussion about date/time parsing a few months
ago -- don't know if it has produced any downloadable effects though.
Maybe we should have a look into that too.

> All the execute() method should care about is the fact that it is a date,
> and the best way for it to tell if its a date, is to have a C based date
> module, and make all your dates as instances
> of types in said module. So that it can just do a type check instead of
> doing "tuple recognition"..

You've got a point there. But again: this module should be a
generic one with a suitable C API for DB modules to use.

Say, the OLE double format... is that the one where the date
is encoded in the whole part and the time in the fraction part ?
Christian told me about such a format.

> 
> The reason for having the above in a C module is two fold..
> 1) Shorten the work the C code has to do to accomplish the input binding to
> the database.
> 2) So the C code can easily create and make use of the date type.
> 
> Again, DO NOT allow a format for transferring dates in strings in your
> Python program...
> Parse a date you get into a date type, and pass that to execute().

Ok.

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