[PYTHON DB-SIG] RE: Date-Time requirements (esp. for databases)

[Petri Raitio]

"Greg" =3D=3D Greg Stein <gstein@microsoft.com> writes:

>> Hardcoding a parser to assume that the use of / as a delimeter means=

>> "US M/D/Y" format would be very suboptimal. I can't see any alternat=
ive
>> apart from making it a switch as to which format you want.

Greg> You need to be *very* careful with "switches." What if my module =
wants
Greg> M/D/Y and yours wants D/M/Y, so we set the flag in the date modul=
e?
Greg> Oops. One of our modules won't work.

I think it's the *user* that wants to work with a certain format, and
this switch should be set in the 'main' program, along with the
language settings.  Modules should use the explicit way,
Date.Date(1996, 10, 31), or if strings are required, with an
universally unambiguous format, which I would suggest be 1996-10-31.
Also, Date.Date("10/31/1996", "%M/%D/%Y") always works, even for Date
subclasses.

Greg> Again, I'll reiterate: I believe that the C module only implement=
 the
Greg> core date-time Type and we punt formatting and parsing up to Pyth=
on.

Greg> Why? Heck... just look at the darn discussion... this amount of
Greg> discussion means that the problem is inherently difficult, prone =
to
Greg> subjective viewpoints and needs, unknown requirements, etc. Creat=
ing a
Greg> requirements or specification for formatting/parsing is just fool=
ing
Greg> yourself into thinking that you got them all.

Just a moment!  What I would like is that the rules would be spelled
out, something like:

* the standard date module contains a Date.Date class that supports
  certain common and useful date formats, such as 1996-10-31,
  10/31/1996, the Unix date command output, and so on

* the DMY order for Date.Date is fixed at M/D/Y, regardless of
  separator, so that there is no confusion with 5/5/5; four digits in
  the first position imply Y/M/D

* I can subclass Date.Date, so that it speaks Finnish, defaults to
  D/M/Y, and whatever

This way, programs written with Date without much thought for non-US
date representations would always allow me to input a safe 1996-10-31,
although I would get 10/31/1996 out.  And I would still have all the
flexibility I need!

</per>

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

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