[DB-SIG] Standardized Date-Time class

[Mike Meyer]

> >  2. Support subtraction of date-times, and addition and=20
> 
>         I think the general idea that time is actually two concepts, Time and =
> TimeSpan, may be the best way of looking at this, and since the way =
> Times are stored may not necessarily be in Seconds since some standard =
> Epoch

It's really only one concept - TimeSpan. A Time is just a TimeSpan
since some standard Epoch. Representing the span as a number of
seconds is easy and has some obvious advantages, but it has serious
disadvantages as well. Since time is easier to type than timespan,
I'll use that instead.

>, adding a number to a Time may be confusing: "What am I adding?  =
> Seconds?  Milliseconds?  Days?  Floating point?  Integer?"

You don't add numbers to a time; you add times to times.  Representing
times as a numeric quantity of some obvious unit makes it look like
you can add numbers, but that's not really the case. However, we want
that to be easy, so some function that has optional arguments for
various time units and returns a time representing the number
specified would be nice.  Have to stop with days or weeks, though, as
months and years have variable lengths.

> >  6. Handle all dates in the Gregorian calendar.  (e.g. there should
> >     not be problems storing dates from the 18th or 21st centuries.)
>         As I said above, supporting non-Gregorian calendars may be made =
> optional, but the Gregorian module should be loaded with the TimeModule, =
> and therefore support of arbitrary Gregorian dates should be feasible.

Is it going to be Gregorian all the way back, or is it going to
convert to Julian at some point in the past? That conversion is recent
enough to effect events of historical interest, not having happened
until this century in some countries.

> >  9. Support for daylight-savings time.
>         Another issue which may be important is that in the US, the rules for =
> when DST begins I believe were changed from beginning the last Sunday in =
> April to the current rules in 1987, so what do we calculate for the Time =
> in mid April in the US before 1987?  Could TimeZones have more than one =
> set of Daylight Savings rules depending on the year being calculated?

That's not the only time that they were changed in the US. And the US
isn't the only place they've changed.

>         What I'm getting at here, is if we are going to support Universal Time =
> from 5 billion BC to 1 billion AD or what have you, we will have to =
> replace the C-Library TimeZone routines with something more robust.  I'm =
> currently examining the GNU implementation of TimeZones and I may =
> elaborate on this in a later post.

I don't know who's C library routines you're using, but the ones
shipped as part of most Unix sytsems are pretty robust. I haven't
checked the GNU version, but I suspect that they're based on the code
that Sun released to the public in '87, which is what most Unix
systems use. These include the ability to externally specify TZ tables
that vary from year to year & locale, and manage to capture such
oddities as Arizona not doing DST at all, and Hawaii having one day of
DST in 1933.

	<mike



_______________
DB-SIG  - SIG on Tabular Databases in Python

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