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

[Bill Tutt]

> -----Original Message-----
> From:	M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de]
> Sent:	Tuesday, December 09, 1997 4:31 AM
> To:	DB-SIG @ Python.org
> Subject:	Re: Date-Time type (was Re: [DB-SIG] DB-API Spec. 1.1a1)
> 
> 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.
> 
This sounds fine, except the time part needs to be more accurate then to the
second..
A float as the # of seconds past midnight sounds fine in this regard.
That way you can still retain the billionths of a second # that you find in
ODBC's TIMESTAMP_STRUCT.
I'm sure other database APIs have things that equivalant to this.

> 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
> 
No, there is only 1 option...
#2, store whatever the user gives us. It is the user's problem to go about
sorting out timezones and DST nonsense.

> 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.
> 
Actually we should supply strptime() in C, esp. since the source is already
availible.
Easiest way to do that is to snarf the BSD libc functions from say:
ftp://ftp.freebsd.org/.25/FreeBSD/FreeBSD-current/src/lib/libc/stdtime
and modify as appropriate.
Locale stuff can be handled with OS's that support localeconv()
We can #ifdef the approriate sections if they haven't already.

So all the C date/time module has to do is:
1) Expose the following date/time type methods
	a)  Construction: taking a # of days since Sunday, December 31, 1
BC,
	     and the # of seconds past midnight
	b)  method to return the # of days, or the # of seconds
	c)  a method that returns a struct tm like tuple like localtime()
returns
	d)  a method that returns a float where the fraction part is: #secs
in a day/#seconds in this instance
2) Expose strptime() that takes a format string, a string to attempt to
parse, and returns a struct tm like structure
    Possibly raising an exception if the string doesn't parse correctly?
3) Method that takes a struct tm like tuple and generates a date/time type.

Everything else should live in Python code.
The ODBC glue code can thusly call dbi.makeDateTime(#days, #secs) (or
whatever the exact name of it is)
The DBI module can then call the date/time type's construction function.

An interesting question in date/time types which there prolly is no RIGHT
answer is:
If my datetime type doesn't store month/day/year information should they be
cached calculations, or should I calculate
them each time?


Bill Tutt
billtut@microsoft.com
Not speaking for Microsoft, etc...


_______________
DB-SIG  - SIG on Tabular Databases in Python

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