Date-Time type (was Re: [DB-SIG] DB-API Spec. 1.1a1)

[M.-A. Lemburg]

Magnus Lycka wrote:
> 
> [ISO dates]
> 
> For me, this doesn't feel like it should be a class of it's own though.
> A date is a date is a date. I'd just like a method to extract the year/week
> number from a gregorian date, but maybe I just haven't gotten used to
> the idea of making this an independent class. Either way, I don't think
> this has a lot to do with the DBI. As long as the DBI supplies a consistent
> date type or class I can have what ever methods I want in external (locale)
> classes. Maybe those classes should just have generic get/set functions à la
> unix date(1) or C's strftime with a default set through locale. (Maybe we
> could just add ISO week as %v. Then I would be happy, but the problem is that
> around the new year %Y and %y might show the wrong year, so we need two more
> year flags, or %v returning 199750 this week.)

I'll have a (proto-)type for date/time handling ready in a few days.
It uses Christian Egli's absolute date as internal date repesentation
(making it compatible to his module) and seconds since midnight as
time basis. The internal calendar used is the Gregorian, all other
notations/calendars can interface to it via the absolute date which
can easily be extracted from Christian's objects.

Right now, I'm curious what you think about the time handling.
We are bound to stumble into daylight savings time here + time zones
which both are hard to handle. While the time zone can be deduced
from time.timezone, the DST can only be guessed at.

There are basically two options:

	1. use GM time (AKA Zulu time AKA UTC) as internal basis
	   and have some external method deduce the DST & time zone
	2. store whatever the user gives to the object and return
	   it in the same way

Option 1 makes date/time calculations accurate to the extent
provided by the external method (i.e. if it knows exactly when
DST gets switched and what the time zone offset is, everything
should work accurate to the microsecond).

Option 2 can produce date/time calculation errors of up
to an hour, but is pretty simple to use.

> Again, this is really not an issue for the DBI though. I agree that dates
> (and timestamps) could be standard Python types.

Which is what we are aiming at... well, at least I am :-) [This isn't
exactly the right place to discuss all this, but the main list is
just too noisy so I'll continue here if noone objects]

> Converting to dates from hand entered strings in all sorts of formats is
> a big mess that should be kept out of a database interface. For instance
> 3/4/5 might at least mean three things (if we agree on which century we
> refer to): 3 Apr 2005, 4 Mar 2005 or 5 Apr 2003. This should be handled
> by Löwis locale stuff.

Conversion from date/time to strings is left to strftime(). The
other way around could be handled by an elaborate module written
in Python (something a la Skip's date.py) -- it's much too messy
to get written in C.

In the end, we could wrap everything up in a nice package...
but there's still a long way to go I'm afraid.

In the meantime, I've put together mxODBC version 0.5, a
preliminary release which knows how to handle both date/time tuples
and time_t values. This will eventually be changed to the
use the new type in a next release. Note that the module
does "tuple recognition" for date/time on cursor.execute()
input and outputs these as indicated by the cursor variable
cursor.datetimeformat. The release is mainly meant to test
portability to Win32. I've included many suggestions from
Christian Tismer, but can't test them myself.

	http://starship.skyport.net/~lemburg/mxODBC.html

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