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

[Jim Fulton]

Petri Raitio wrote:
> 
> "Jim" == Jim Fulton <jim.fulton@digicool.com> writes:
> 
> Jim> I want a constructor something like this:
> 
> Jim>   DateTime(*args) -- Return a new date-time object
> 
> This is great, I'd love to give up maintaining My Own Date module!
> 
> Jim>   The date component consists of year, month, and day values. The
> Jim>   year value must be a two- or four-digit integer. If a two-digit
> Jim>   year is used, the year is assumed to be in the twentieth
> Jim>   century. The month may an integer, from 1 to 12, a month name,
> Jim>   or a month abreviation, where a period may optionally follow
> Jim>   the abreviation. The day must be an integer from 1 to the
> Jim>   number of days in the month. The year, month, and day values
> Jim>   may be separated by periods, hyphens, forward, shashes,
> Jim>   underscores, or spaces. Extra spaces are permitted around the
> Jim>   delimiters. Year, month, and day values may be given in any
> Jim>   order as long as it is possible to distinguish the components.
> Jim>   If all three components are numbers that are less than 13, then
> Jim>   a a month-day-year ordering is assumed.
> 
> I'd like to have less chance for misunderstanding here.  I think there
> should be a default format with a *fixed* DMY order, so that I could
> tell the user that 10.30.1996 is not a valid (European) date.

I think that this should be an option.  That is, the programmer should
have 
a flag, or perhaps a subclass, that enforces rules like you just
mentioned.

> 
> I wonder if it would make sense to use the separator as a format
> specifier and have format-specific DMY orders, so that 10/30/1996 and
> 30.10.1996 would be valid dates but 30/10/1996 and 10.30.1996 would
> not.  This way, it would be easy for us Europeans to specify a native
> format date in a program written in the US.

This is an interesting idea.  Is the correlation between delimiter and
order really that strong?
 
> Jim>   The time component consists of hour, minute, and second values
> Jim>   separated by colons. The hour value must be an integer between
> Jim>   0 and 23 inclusively. The minute value must be an integer
> Jim>   between 0 and 59 inclusively. The second value may be an
> Jim>   integer value between 0 and 59.999 inclusively.
> 
> My crazy ctime(3) man page tells me seconds are in the range [0, 60],
> and the ANSI C standard makes this a bit crazier, [0, 61]!  These are
> a provision for leap seconds, up to two of them.  But maybe we don't
> really care to be *that* precise, I'm sure nobody's localtime() will
> actually return them..

Does anyone (in this discussion) know the rules for leap seconds?  
 
> Jim>   If the DateTime function is invoked with two string arguments,
> Jim>   then the first argument is treated as a format string and the
> Jim>   second argument is parsed as a date-time value according to the
> Jim>   format string.
> 
> Just a detail: wouldn't this be nicer the other way around, as in
> foo(str, fmt = "<deffmt>")?

I don't have a strong opinion on this.  I was just following hysterical
conventions (e.g. scanf).
 
> Jim>   Two-digit years are assumed to be in the twentieth century.
> 
> This definition will become obsolete in a few years!  Did you mean in
> the *current* century?

Actually, the "current" century definition would be very dangerous. 
There
are alot of data sets that use 2-digit years and all of these would
break
on Jan 1, 2000 if a "current" century definition was used.
 
> Jim> Data such as month and day names would be stored in dictionaries
> Jim> as class attributes that could be replaced with locale-specific
> Jim> values.
> 
> Fine, this is absolutely required!  Note, that the system locale is
> not very useful, so the strings need to come from the module that uses
> the Date module.  (I don't want my 'ls' to tell me a file is dated
> '30 Loka' when it is really 'Oct 30'.)
> 
> I would also like to see operations for inquiring week number and
> day-of-week information; I have a week number algorithm that returns
> correct week numbers according to the definition here in Finland, but
> I'm not sure how universal this is.  (Weeks start with Monday; the
> first Friday in January is always on week 1; thus the week number can
> run up to 53, the last week in a year can be number 1 from the next
> year, and the first week can be 52 or 53 from the previous year.)

I've done day-of-week in the past.  Week number is an interesting idea,
but it sounds like it lacks a universal definition.

Note that the DateTime class (whether implemented in C or Python) will
be subclassable so perhaps features like "week number" should be defered
to subclasses.

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