Datetime utility functions

[John Roth]

"Paul Moore" <paul.moore at atosorigin.com> wrote in message
news:brtl7s6v.fsf at yahoo.co.uk...
> "John Roth" <newsgroups at jhrothjr.com> writes:
>
> > "Paul Moore" <paul.moore at atosorigin.com> wrote in message
> > news:182bcf76.0309150707.3a8c0482 at posting.google.com...
>
> >> 1. Get the last day of the month contatining a given date(time). I
> >> really was surprised to find this one missing, as it seems to me that
> >> the datetime module must know what the last day for each month is, so
> >> exposing it wouldn't have been hard.
> >
> > I'm kind of surprised to see that it's missing, too.
>
> The best solution I could find was
>
> def month_end(dt):
>     # Get the next month
>     y, m = dt.year, dt.month
>     if m == 12:
>         y += 1
>         m = 1
>     else:
>         m += 1

This looks incomplete. You could use this to get the sequential date
for the first of the next month, but you still have to subtract one day
and then print out the day.

>
>     # Use replace to cater for both datetime and date types. This
>     # leaves the time component of a datetime unchanged - it's
>     # arguable whether this is the right thing.
>
>     return dt.replace(year=y, month=m, day=1) - datetime.timedelta(days=1)
>
> It's not hard - but it's mildly tricky (I made a few false starts and
> some silly off-by-one errors) and I'd much rather grab it from a
> library than make the same mistakes next time I need it.

As I said, I don't see any obvious reason why they wouldn't accept
a patch, if you want to submit it.

> >> 2. Add a number of months to a date. This is messy, as there are
> >> options (what is one month after 31st Jan). The trouble is that the
> >> calculation, while simple, is tricky to get right (month is 1-based,
> >> so off-by-1 errors are easy to make, and divmod isn't as useful as
> >> you'd first think).
> >
> > That's application dependent.
>
> True. But for "naive" use, a simple definition does. This is in line
> with the datetime module's philosophy of not trying to cater for
> "advanced" uses, but to provide something useful for straightforward
> use. In this particular case, I'd argue that the obvious definition
> (same day number N months on) where applicable, plus a well-documented
> "reasonable" answer for the edge cases (eg, Jan 31 plus 1 month) is
> useful. In practice, I suspect that 99% of cases involve adding a
> number of months to either the first or the last of a month.

Except for the edge case I mention below, this is really too simple;
it's just add one to the month and keep the same date. Hardly worth
a method at all, especially if you have the "last day of month" method.

> > If a bond, for example, has interest payable on the 30th of the
> > month, you probably want the 30th, except in February you want the
> > last day of the month. However, the contract may specify something
> > else. And in no case do you want the date to suddenly change to the
> > 28th because you went through February.
>
> But that's not so much a case of adding a month, as a more complex
> concept, a "repeating date". Nevertheless, I take your point.

Yes. When you've got something application dependent, they tend
not to put in "naive" definitions. What's a 'naive' definition for one
person
is simply wrong for another.

John Roth


> Thanks for the comments,
> Paul.
> --