The "beaty" of date arithmetic

[Hans-Joachim Widmaier]

"John Roth" <johnroth at ameritech.net> wrote in message news:<v3b3h9gl7vha60 at news.supernews.com>...

> What's even uglier is that you're mixing spaces and tabs for
> indentation.

Vim does it, and it does it right, as I *never* indent using <Tab> or
pressing my space bar several times. I use the appropriate indent or
detend commands. And I never ever had any indentation problems in
python. As long as a tab goes to column 8*n+1, everything's ok. And
you certainly don't want my opinion on Outlook Express. ;-) (I also
admit that I thought the tabs would be lost by cutting and pasting
into google's text entry. I was wrong.)

> What I usually do is convert dates to astronomical days and then
> do the arithmetic. (Astronomical days begin at 0 for some day
> in 4700 BC, and count up from there.) Months are 30.6 days and
> years are 365.2425 days. You can get awfully close, which is quite
> good enough for me.

Everything would be fine if date and time was a monotonically
advancing value like seconds since the big bang. :-) Alas, our civil
time is a complicated mess (and there are still other calendars that
are *much* more complicated as our gregorian). Problem is, problems in
"human space" should deal with "human dates", not abstract ones.
"Awfully close" is only second best when it can be exact.

I keep repeating myself: It's not the ugliness of being unable to
subtract or add one calandar month I'm complaining about. It's the
ugliness of the code that I wrote. I just hoped someone had an idea
how it could be more readable.

Whatever, it works albeit being no top runner in the
prettiest-function-of-the-year contest, and 2.3 is on the horizon,
promising some relief.

It's really not such a big thing, let's lay it to rest.

Thanks to all of you,
Hans-Joachim