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

M.-A. Lemburg lemburg@uni-duesseldorf.de
Tue, 09 Dec 1997 21:22:09 +0100


Mike Meyer wrote:
> 
> > 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.
> 
> Actually, the DST information is available on most Unix systems,
> derivable from the time & timezone information. The code for doing
> this is publicly available, and fairly easy to port to things that
> aren't Unix. One would hope that the C library routines used by the
> Python time module used them, and the compiler vendors did the port
> (or an emulation).

I looked at the manpages, but couldn't find any hint as to
how to determine start and end of the DST, if not given by the
environment variable TZ. Looks like we'd have to probe mktime/
localtime to find out. There's lots of information in the 
tzfiles, but I haven't (yet) found a usable interface to access it.

> 
> > 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
> 
> The longer I look at this, the more confused I get. Could you provide
> more details about what you're contemplating? I know what I think it
> should do, but...

If we'd use UTC as internal basis (which is what I am favoring
at the moment since the C functions use the same basis for the
time_t values), conversion functions/methods are necessary and
these are like most locale dependant stuff bound to change now and
then.

If we leave the semantics of the stored value to the user, nodbody
but him/her would know e.g. if the times use DST or not. On the other
hand no conversion is necessary at all. Time calculations can
result in errors though, if e.g. you compute the difference between
a date in summer and a date in winter.

A good compromise, IMHO, is to provide an interface for conversion
much like the one dates will use. Those who need special
things in this respect can then easily code their locale dependant
conversion in Python. I'm thinking here of something along the lines
of the copy_reg-module with which you can register new pickle handlers.

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