skip@calendar.com wrote:
Jim> The problem is that DateTime wants to support offsets in seconds Jim> from the epoc *and* offsets in days from 1901-01-01. This approach Jim> is flawed. (It results from some interface baggage from some older Jim> date-time implementations of mine.)
Jim> I'm inclined to change DateTime to only expect epoch offsets in Jim> seconds when a single numeric argument is given. This will be Jim> changed in the next release.
Since time.time() returns a float and the number of days since 1901-01-01 would normally be considered an int,
That was not the intent. You can have fractional days just as easily as fractional seconds.
why not interpret single floating point args as seconds since the Unix epoch and ints or longs as days since 1901-01-01? This would be easily enough explained in the documentation and would perhaps induce less breakage in existing applications that use DateTime.
I don't think that this is going to break any current usage. Note that I'm also changing __int__, __long__, and __float__ to return seconds since the epoch. This will make: DateTime(float(d)) == d In the current implementation, the above expression is true sometimes, false others, and often raises an exception. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.