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

[Michael McLay]

Anthony Baxter writes:
 > 
 > >>> Michael McLay wrote
 > > 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].  
 > 
 > But this also reduces the usefulness of the DateTime class - we should be
 > able to parse dates, as returned by various systems, and produce something
 > useful out the other side. Insisting that the input is always in a particular
 > format breaks this.

I'm not saying this shouldn't be supported.  It just shouldn't be
supported in the core module.  Make the core module completely safe
and then import that module into a module with lots of really useful
and general purpose readers.  (This extension should still only output
in the standard format.)  Then finally make a third module that
imports the middle layer which includes general purpose output
capabilities for everything from a Roman numeral syntax to a Chinese
calendar.  

This approach allows code to be scanned for things that may be
dangerous by looking for the layer 2 or layer 3 module names.
Anything that uses layer one is presumed safe.  
 > 
 > For example, _right_now_ I have systems that have to parse dates that are 
 > in the following formats. (bonus points to anyone who can identify where 
 > these are all from :)
 > 
 > Thu Oct 31 10:32:20 EST 1996
 > 23:08:50 UTC Sat Oct 19 1996
 > Oct 27 04:01:17 
 > Fri, 27 Sep 1996 10:25:23 +1000
 > Thu Oct 31 10:36 EST 1996
 > 28 Oct 96 23:34:02 GMT

Layer 2 should be able to read each of these, but Layer 1 and layer 2
shoould be assumed safe for outputing in a standard notation.

 > > 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.
 > 
 > Again, an awful lot of stuff out there produces dates with 2 digit years.
 > The suggestion I made earlier (make it handle 2 digit years by picking the
 > closest one to 'now') would seem to handle this reasonably well - assuming
 > that the only two digit years out there are produced by other computer systems,
 > so you're not likely to get something outputting '11/11/18' meaning 
 > 11 Nov 1918, but you are likely to get something outputting '23 Oct 93'
 > meaning 1993. Yes, it would be nice if everything used 4 digit years, and
 > all new systems should _only_ output 4 digit years[*], but I don't see a problem
 > with being able to parse 2 digit years as input. 

I agree you need to be able to read in the old formats, but keeping
the modules for backward compatiblity separate allows the programs
that are standard comformant to be more efficient and easier to test.

 > [*] I'd suggest that the formatted output method of the datetime class not
 > have a code for two digit year. If they really want a two digit year, make
 > em work for it :)
 > 
 > > 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.
 > 
 > Hardcoding the TZ is not good enough. 'site.py' is for a python installation, 
 > not for a site. eg, koro.off.connect.com.au:/opt/python/lib/python1.4/site.py 
 > is used by computer systems in 7 different timezones.

I hadn't expected that.  Of course you could have the site.py file
look at the local timezone in a site/timezone. files.

 > I like Jim's idea of making timezone handling a seperate module - systems 
 > that support timezones reasonably can deal with them, then.

Ok.

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

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