[PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases)

[Jim Fulton]

W. Craig Trader wrote:
> 
> On Wed, 30 Oct 1996, Anthony Baxter wrote:
> 
> > Other methods the DateTime objects should have:
> >
> > strftime   - takes a format string, returns the date as a string in the
> >            specified format. ("%Y%M%D %H:%M:%S" -> "19961029 11:57:00")
> 
> This is good, though it duplicates the existing `time' modules function.
> 
> > arithmetic - difference between two dates. adding dates - it should be
> >            possible to produce a DateTime object representing "1 week"
> >            and say DateTime(now) + DateTime("1 week").
> 
> I think you're wrong here - there should be multiple types:  DateTime, as
> already discussed, and Interval, which would represent a signed quantity
> of a generic unit (ie: 10 minutes or 2 hours or 1 week or 5 years), or
> possibly a combination.  Math would look like this:
> 
>         Interval + Interval => Interval
>         Interval - Interval => Inverval
>         DateTime + Interval => DateTime
>         DateTime - Interval => DateTime
>         DateTime - DateTime => Interval
> 
> Since we're talking about databases, the types should try to stick fairly
> close to SQL, and SQL/92 already has provisions for DateTimes and
> Intervals.

What is the rational for using a dedicated Interval class rather than
just
using numbers with agreed units. (See my other note?)  Is the benefit
worth the added class?

> 
> > Timezones. If the OS supports timezones, it should use it. Yes, this incurs
> > some portability hassles, but that's the way things are - under Unix, the
> > timezone support is very good, and should be used. If Windows or whatever
> > has inadequate support for timezones, then something else should be provided
> > for that.
> 
> Again, I'd want to look towards SQL for this type of problem - the
> theory's probably already been solved - why work hard only to produce
> something that isn't compatible with major databases?

My inclination is to leave this issue somewhat open.  I'm going to
propose that
Date-Time objects have optional time-zone attributes that may be bound
to
time-zone objects that can convert from a base time (e.g. GMT) to
"local" time
and make the implementation of time-zone objects independent of the
implementation
of date-time objects.
 
> > Hardcoding timezones is something that should be avoided. Particularly with
> > daylight savings, which is a hideous political issue. Australia has 8 states
> > and territories - nearly every one of these has different timezone/DST rules.
> 
> Well, at least South Australia is no longer 1.5 hours off from Queensland.
> That was a *real* lousy system.  Of course, Indiana in the States is the
> worst - it varies county by county.  <sigh>

Hee hee.

Jim
-- 
Jim Fulton         Digital Creations
jim@digicool.com   540.371.6909
## Python is my favorite language ##
##     http://www.python.org/     ##

=================
DB-SIG  - SIG on Tabular Databases in Python

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