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

[Anthony Baxter]

>>> Jim Fulton wrote
> Petri Raitio wrote:
> > 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?

I doubt it. Australia uses D/M/Y, and, f'r instance, every piece of paper 
I've seen from a bank has a field like   __ / __ / ____ and expects day, 
month, year. (actually, they usually have it like __ / __ / 19__, but that's
just banks being morons.)


> Does anyone (in this discussion) know the rules for leap seconds?  

I've fired off some mail to some people I know who may be able to help.

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

How about we compromise - a 2 digit year will refer to the _closest_ year 
with the last two digits.  (96 = 1996, 02 = 2002, 85 = 1985...)
 
> > 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'.)

Make a DateI18N module to hold all this sort of stuff.


Anthony

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

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