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

[Petri Raitio]

"Jim" =3D=3D 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 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.

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

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 =3D "<deffmt>")?
  =

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?

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

</per>

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

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