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

[Michael McLay]

Petri Raitio writes:
 > 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.

The ambiguity of DMY or MDY notation can be avoided by using
1996/10/30 instead of DMY or MDY notation.  Standardizing on this also
has the side effect of making string sorts of dates be chronologically
ordered.  This date ordering is the recommended practice for
U.S. government agencies[1].  

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

Using two-digit numbers for representing years is an avoidable source
for errors in coding.  Not allowing years to be less than 4 digits in
the new date module would make Python "Year 2000" safe.  That would be
a good attribute to put in Python's feature list considering the
growing concern over the problems that are anticipated on Jan 1, 1999.

Time is independent of the calendars we use so an internal
representation only needs to count units of time and establish what
point in time the Epoch, time=0, represents.  The POSIX standard
arbitrarily assigns the date January 1, 1970 in Coordinate
Universal Time.  All local time calculations, such as leap seconds and
daylight saving rules, are then simply offsets from the Epoch.  The
local offsets are arbitrarily set by local laws.  Since these local
laws are subject to change the core date module should avoid
integrating them into a standard Python module.  Perhaps the setting
of the local time offset should be added as a feature of the new
site.py module.

If signed long integers are used to represent time then running out of
digits is no longer a problem.  This would allow the time increment to
be lowered to microseconds, which would be helpful for some scientific
calculations.  Since computer speeds continue to increase this may
also be helpful in operating system level functions as well.  From a
performance angle it might be better to use 64 bit integers for the
representation internally.  A 64 bit signed integer with microsecond
resolution would provide at least 10k years of trouble free
programming.  (10k years is my cutoff on worrying about future
problems:-) Of course this might cause problems if someone is doing
calculations that date back to the origins of the universe, or when we
can expect the national debt to be paid.


[1] "REPRESENTATION FOR CALENDAR DATE AND ORDINAL DATE FOR
INFORMATION INTERCHANGE" at http://www.nist.gov/itl/div897/pubs/fip4-1.htm
FIPS 4 was originally issued in 1961.  The original version allowed
for an optional two-digit representation for year.  This was recently
changed to require the year to be represented as four digits.

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

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