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

[Christian Tismer]

Magnus Lycka wrote:

> At 16:11 1997-12-08 +0100, M.-A. Lemburg wrote:
> >[Lots of code from Christian Egli]
> >
> >What an impressive list of date formats, thanks. I think we
> >should (at first) stick to Gregorian and Julien dates for
> >input/output methods. Your "absolute date" basis seems to be
> >a reasonable internal format for the date integer. Time
> >could be encoded as double expressing seconds since midnight.
> >This is pretty accurate and allows for leap seconds etc.

Yes please.I don't care of any-alian dates at all. I just have to
usedatabases of people who live now or some years ago. This is what
I have to deal with, and I think it is  true for a lot of us.

> ...

> 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

Right. DBI should handle dates, but not try to implement them.

> 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 suppose it's understandable that for instance Oracles SQL which has
> evolved
> into a more extensive programming language and is used for ad hoq
> generation
> of reports etc support advanced date formatting, but if we write
> programs
> in a full language like Python we have no reason to mix data entry or
> display
> functionality with storage. In other words, lets have nice date
> formatting
> functions, but not in the DBI.

I think this is write. Let's try to carry a date, which a database gives
us,around, and ok. The more interpretation takes place, the worse.
...
Dates are not an easy theme. And also they are not very popular.
The people who are actually dealing with it, don't have the problem to
move between different calendars. They simply want to see their
own birthdate as a native date constant:-)
(god am I old).

Wha about this: KISS, but no simpler?

cheers - pirx


_______________
DB-SIG  - SIG on Tabular Databases in Python

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