[DB-SIG] ANN: DateTime type, version 0.1

[Jeffrey C. Jacobs]

-----Original Message-----
From:	M.-A. Lemburg [SMTP:lemburg@uni-duesseldorf.de]
Sent:	Friday, December 12, 1997 10:06 AM
To:	DB-SIG @ Python.org
Subject:	[DB-SIG] ANN: DateTime type, version 0.1

Now that we have decided on the need for a basic date/time
type and more or less settled on what it should be able to do
and what not, here it is:

    http://starship.skyport.net/~lemburg/mxDateTime.html=20

You'll find all information regarding the type, how to download
and install it on that page. Future releases will also use
that URL.

I plan to upload the archive to www.python.org and - if you
all agree - update the DB API Spec. 1.1 to make it the
standard for date/time value passing in and out of databases.

While I am going to support this module, I am counting on
you out there to provide classes on top of this
type to do all the nifty stuff we've been talking about
here lately. Christian Egli's classes should can use the type
directly since it uses the same absolute date numbering.

Note: the mx-prefix is just for packaging, the module
itself is named 'DateTime', just like the data type it
provides.

If you don't have a strptime() function in your C lib,
then you should undefine this (HAVE_STRPTIME in the C file).
Guido will include a patch for the configure script in the
final that does this check for you.

[The TimeHorse]-----------------------

	Cool!  It looks great, though one thing I might point out is that leap =
seconds are calculated as the 60th second of the 23rd hour of the 59th =
minute.  Thus, there is no 24th hour on leap-second days, only that =
extra 60th second.  There's a cool picture on the web somewhere which is =
taken from the USNO atomic clock during the last Leap Second on 30 June =
this year, which shows the 60th second.
	I know you probably don't agree with me on the suggestion I am going to =
make, and this has been discussed quite a bit already and maybe we're =
all sick of it, but I still feel a co-class of type TimeSpan would be =
good, as it makes the future operations of addition and subtraction a =
lot more clear.  One suggestion made by Jim Fulton the other day sounds =
appealing to me too, which is the idea of a separate Date and Time =
class, so that the DateTime constructor can accept the immutable Date =
and Time object, as opposed to the Absolute date and time values.  Of =
course, this is only a semantically point, and doesn't really effect =
much, and some may feel it over-complicates things, but certainly there =
are circumstances when you may only want to retrieve a date, not a time, =
in your Database, and may not want the overhead of the time functions, =
and visa-versa.  I must admit another problem with my suggestion, which =
is that if one applies a TimeZone change to a Time object, what does it =
mean if the result spans more than one day?  It is possible the time may =
end up internally as negative, or greater than 24 hours.  Despite these =
problems, I still tend to lean more towards the 4-class model, or at =
least the 2-class (DateTime and TimeSpan).
	Okay, I've said my peace and will depart now.  I look forward to the =
new Database support and am happy that it is now very nearly complete.  =
Thank you all!

			Be Seeing You,

			Jeffrey.

---
~,-;`  The TimeHorse
Sometimes also a Dragon. . .



_______________
DB-SIG  - SIG on Tabular Databases in Python

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