[Python-Dev] functions exposed by datetime (original) (raw)

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