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

[Anthony Baxter]

> > What are you thinking of?  How do you plan to achieve genericity
> > without some kind of template, or format string?
> 
> Yes.  I've done this before.  It's not practical unless it is 
> done in C.

For an example of a way of doing this, check Perl5's Date::Manip
package - it's kinda neat (although sloooow).
The hassle with providing default ways of converting is that it leads
people to expect you to be able to deal with anything. I was bitten by
this recently - a cisco generated dates like "29 Oct 1996 UTC 11:57:23"
and the UTC bit broke the ParseDate function.

> In this case, I'd be inclined to provide handling of a very 
> wide variety of formats without requiring format strings, 
> but allow the specification of format strings as well.

(Rather than/as well as) a format string, I'd like to see the ability to 
provide a regexp with symbolic group names for getting the dates out.
This is a bit more powerful - you can deal with virtually anything then :)

Perhaps we can provide a collection of standard ones...

>   If the function is invoked with a single string argument, then the
>   string is parsed as a date-time value. If the string contains a valid
>   date-time value, then the corresponding date-time object is returned,
>   otherwise a DateTime.error is raised. As a general rule, any date-time
>   representation that is recognized and unambigous to a human is
                                       
"unambiguous" is a problem. What's 03/06/96 represent? 3rd June, or 
6th March? Date::Manip has an option you set for US mode (M/D/Y), or 
everywhere else (D/M/Y) mode.

>   acceptable.  A date-time string consists of two components, a date
>   component and an optional time component, separated by one or more
>   spaces. If the time component is ommited, 12:00am is assumed.

I'd also like the ability to just give it an int from time.time(), but
that may be just my unix bias showing. I'd be happy with just

DateTime("1 Jan 1970 00:00:00 UTC") + DateTime("%d seconds"%time.time()).

>   long as it is possible to distinguish the components. If all three
>   components are numbers that are less than 13, then a a month-day-year
>   ordering is assumed.

I have a problem with this default (see above) - it should be selectable.
  
Rather than having behaviour depend on the number of arguments (which means
people are going to be running for the docs far far too often), why not use 
keywords? 

DateTime.DateTime(year=1996, day=200)
DateTime.DateTime(year=1996, month=5, day=20)

> The description above is from my current DateTime module, except that
> I've added provision for an optional format string.
> 
> My thought is that there would be a DateTime class that would be
> called to create instances as described above.  Data such as 
> month and day names would be stored in dictionaries as class attributes
> that could be replaced with locale-specific values.

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")

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").

conversion to/from dbiDate objects.

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.

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.

Anthony

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

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