[Ajith Prasad]
> ...
> The difficulty I had with the mxDateTime module was that results
> seem to be expressed as date time objects with timestamps embedded
> with dates and, given my limited knowledge of Python (just a few
> chapters into "Learning Python") I have no clue as to how to extract
> just the dates out. But I am sure that mxDateTime has all the
> functionality that justifies further investment in learning it.
An interactive shell (IDLE or PythonWin work great) is your best friend,
along with the "dir" function, __doc__ strings, and just *trying* stuff;
e.g.,
>>> import DateTime
>>> dir(DateTime) # see what's in the module
['ARPA', 'Date', 'DateTime', ...]
>>> print DateTime.Date.__doc__ # what does Date do?
DateTime(year,month=1,day=1,hour=0,minute=0,second=0.0)
Returns a DateTime-object reflecting the given date
and time. Seconds can be given as float to indicate
fractions.
>>> t = DateTime.Date(1999, 6, 20)
>>> t
<DateTime object for '1999-06-20 00:00:00.00' at 794810>
>>> dir(t) # see what t can do
[.'COMDate', 'Format', '__copy__', '__deepcopy__', 'absdate',
'absdays', 'abstime', 'absvalues', 'day', 'day_of_week',
'day_of_year', 'days_in_month', 'hour', 'is_leapyear', 'minute',
'month', 'second', 'strftime', 'ticks', 'tuple', 'tz', 'year',
'yearoffset']
>>> t.day # try something
20
>>> t + 20 # try adding
<DateTime object for '1999-07-10 00:00:00.00' at 794100>
>>> # looks like "+ int" adds that many days;
>>> # wonder whether printing is prettier
>>> print t + 20
1999-07-10 00:00:00.00
>>> # yup!
That's how you get amazingly good at Python amazingly fast <wink>.
> In response to my posting, Tim Peters and Jeff Bauer have pointed out
> simpler date-time routines that could be used. Tim's routines (available
> together with the Python source code disribution) use the American-style
> "month-day-year" format while Jeff's use the less ambiguous
> "year-month-date" format which also happens to be the format in which my
> date data are in.
FYI, Tim's code was actually written as a demo of then-new operator
overloading facilities. That it happens to do anything sensible with dates
for anyone is a reliable accident <wink>.
OTOH, don't let MDY year stop you! Python excels at gluing things together,
forcing nasty interfaces into forms that *you* like; e.g., it's a one-liner
to write your own little function to accept YMD argument order instead,
passing it on to Date's constructor in the order *it* likes. Do it once &
never think about it again.
> Jeff's notes at http://starship.python.net/crew/jbauer/normaldate/ make
> some useful points on the need for simple routines which handle the
> more common date arithmetic tasks without the added complications of
> dealing with specific calendars, time zones, etc.
Jeff has a very nice pkg there. I recall that when I first tried it, I was
baffled by the results until I dug into the code & saw it special-cased the
snot out of the year 1582 <gregorian wink>. Dates.py takes a more extreme
view of simplicity, pretending today's rules extend infinitely in both
directions. Of course that's *wrong* -- but then so is ignoring leap
seconds <wink>.
> Both Tim's and Jeff's routines are geared towards this. I will look at
> the further references that Ivan has suggested for a deeper
> understanding of the issues.
No no no, Ivan is a calendar *expert*: he'll only break your heart. It's
like asking me what 1.1 + 0.9 should return <wink>.
experts-can't-abide-simple-answers-because-reality-is-a-
frickin'-mess-ly y'rs - tim