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

[Anthony Baxter]

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

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

> 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'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 like Jim's idea of making timezone handling a seperate module - systems 
that support timezones reasonably can deal with them, then.

Anthony

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

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