[PYTHON DB-SIG] [comp.lang.python] Date-Time requirements (esp. for databases)
Wed, 30 Oct 1996 08:24:27 -0500
Petri Raitio wrote:
> "Jim" == Jim Fulton <firstname.lastname@example.org> 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
a flag, or perhaps a subclass, that enforces rules like you just
> 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.
are alot of data sets that use 2-digit years and all of these would
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
Jim Fulton Digital Creations
## Python is my favorite language ##
## http://www.python.org/ ##
DB-SIG - SIG on Tabular Databases in Python
send messages to: email@example.com
administrivia to: firstname.lastname@example.org