skip@calendar.com wrote:
Hmmm... I received two negative replies to my DateTime constructor suggestion almost immediately. Obviously it was not well-received. :-)
My original question asked why the behavior of the DateTime constructor was so unobvious in the face of apparently simple initial values like 1. Jim responded and indicated he was going to (I believe) discard the interpretation of small numeric initializers as days since 1901-01-01 in the next release. I looked at that and thought, "Geez, Jim is probably going to have to fix a number of places where DateTime(10) means 1901-01-11."
Nah. This was really meant to allow DateTime(float(d))==d where float(d) returned days. Changing both to use seconds consistently addresses the original need.
Then I thought there might be a middle ground, and proposed that. It's certainly no worse than the current behavior.
True.
Granted, a little weird, but still, unambiguous.
But I think that the proposal to just interpret a single number as a seconds since the epoch is a little better.
I suspect that within the non-Unix world "days since 1901-01-01" is at least as useful a time measurement as "seconds since 1970-01-01:00:00".
Actually, the time.time notion is based on ANSI C's notion of seconds since an epoch, which may not necessarily be 1970.
I'm not much of a database person, but my brief brush with SQL suggests that not having a way to initialize a DateTime using some sort of "days since 1901-01-01" numeric value is going to be a problem. Perhaps it can be tweaked to accept one or more of
"%d days" % n "1901-01-01 + %d" % n
as valid string initializers.
I think that: DateTime(1901,01,01) + days is good enough. This is the current behavior. Note that I have kept the current days units for addition and substraction. This is a little inconsistent, but changing it would break a bunch of existing code. It would be better, in the long run to have a more explicit notion of duration.
I deal with dates all the time on Musi-Cal, not wide ranges of dates like database folks do, but human meaningful dates like "all of November", "Sept, Oct, Nov", "after July 4th", "June thru September" or "any". Unfortunately, I still have to discard most of those meaningful, unambiguous dates because I don't have time to build and continually tweak the mutha of all date string parsers. I do handle some other obvious ones like "Christmas" and "New Year's Eve", though not "Thanksgiving". Maybe DateTime can evolve into such a mutha. Jim, if you'd like some sample input, I have log files full of dates for you... :-)
While I'm daydreaming, I'd like to see DateTime or some other timestamp beast be able to represent relative times like "the next two weeks", so that the absolute value changes depending on when the object is evaluated. That would be the cat's pajamas.
I tend to like this sort of idea, although it tends to get me in trouble. ;) As date parters become more user friendly, they also get to application/local-specific. There should probably be a more modular way to handle date partsing that is separate from the core date-time type. There's something to be said for the approach taken by mxDateTime, which doesn't provide string parsing at all. 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.