[Zope] - Some DateTime behaviors I just don't understand

[Jim Fulton]

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.