Re: [boost] [date_time] quarters as new durations?

Subject: Re: [boost] [date_time] quarters as new durations?
From: pete_at_[hidden]
Date: 2009-12-22 08:50:47

On Tue 22/12/09 13:27 , "Stewart, Robert" <Robert.Stewart_at_[hidden]> wrote:

> Jeff Garland wrote:
> > Stewart, Robert wrote:
> > > Thomas Lemm wrote:
> > >> I am happily using the boost date_time library and I plan to
> > >> extend it towards including quarters as new (gregorian) date
> > >> durations, just the way months are included already
> > >> (excluding parsing of quarters)
> > >
> > > Why excluding parsing?  That would imply only partial
> > > support relative to other durations, right?
> > >
> > Well, so quarters turns out to be like months as far as
> > durations go -- that is, it's mathematical like days and
> > weeks. So the big drawback you face is dealing with the
> > associated "fuzzy math".  For example, what's the result
> > of
> >
> >    date("2008-Feb-28") + quarters(1) = ?
> >    date("2008-Feb-27") + quarters(1) = ?
> >
> > Month durations play some games to handle this problem (see
> > docs for details) which quarters could adopt.  But if you
> > adopt the month rules then I don't thing you buy much more
> > than simply writing
> >
> >    const months quarters = months(3);
> That's an excellent point.  I don't think the fuzzy math approach is
> appropriate for quarters because they have a precise definition: 1/4
> of a year.  Months are less precise, though 365 / 4 is not a whole
> number, of course.

Possibly opening a can of worms here, but a quarter in my line of work is invariably three months. If your mileage varies, then there could be a problem in providing a fully meaningful quarter duration type if people think it means different things.

> There is probably still a need to use some fuzzy math in order to
> determine the calendar date for quarter boundaries.  Quarters are
> usually associated with a fiscal year and there are different
> definitions of those, so you probably need to add fiscal year support
> and make quarters a derived concept.
> > There's also an argument against adding quarters as a
> > duration.  I have an app somewhere in which I have quarter
> > defined as a date_period so I could write:
> >
> >     date_period q = quarter(2009, 1);
> >
> > To me at least this seems like the more likely application.
> I agree.  I didn't consider the ramifications of duration versus
> period.

The issue routinely occurs with months already though. Month durations and date_periods spanning a specific month already have to work closely with each other:

date_period month_containing(date d) { return date_period(date(d.year(),d.month(),1) , months(1) ); }

so it may not be a big issue.