[Python-Dev] functions exposed by datetime
Manuel Garcia, VP MIS
mgarcia@cole-switches.com
Wed, 15 Jan 2003 11:58:13 -0800
The more I read about "datetime", I am beginning to realize that like
"mxDateTime", it is a needlessly awkward to use for people who want to
cheaply turn a calendar date into a 32 bit integer, and back again. (an
integer suitable for doing date arithmetic, of course)
for example:
2/28/2004 38045
2/29/2004 38046
3/1/2004 38047
3/2/2004 38048
No matter how complete "datetime" turns out to be, you will have thousands
of programmers that will have to code their own company's fiscal calendar
anyway. So it makes sense to have cheap access to date arithmetic logic.
(I work for a manufacturing company, our fiscal months and years always
begin on a Sunday, fiscal years are exactly 52 or 53 weeks long, and the
length of a given year is determined as much by the tax code as by the
positions of the earth and sun.)
And what is day zero? Who cares? Already I have to keep track of Excel's
day zero, PICK (legacy database) day zero, Unix's "day zero", fiscal
calendar "day zero", so keeping track of one more is no big deal, since
obviously they only differ by a constant. And most of the time, day zero is
irrelevant.
Besides date arithmetic, there are other reasons to make conversion between
dates and integers very cheap. 32 bit integers obviously are easy to store,
hash perfectly, can be quickly put into bins with use of "bisect", and they
make calculations that loop over every day in a month or year a simple loop
over a range(x,y).
The hashing is the biggest concern. If I understand correctly, Guido said
hash for datetime objects was not straightforward, because the same day can
have more than one representation. I am constantly using a "date" for part
of a dictionary key.
Sourceforge is gagging right now, so I cannot confirm what is in "datetime",
but I never heard any mention of cheap conversion of dates into integers.
My current fiscal calendar code uses mktime, localtime, int(round(x + (y -
z) / 86400.0)), and prayer. Currently the program is swamped by I/O, so
this is good enough, and I can't justify installing "mxDateTime" on all the
client machines. But I wouldn't mind using a simple, cheap built-in.
Manuel Garcia
Email mgarcia@cole-switches.com