[date_time] quarters as new durations?
Hi, 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) Now my question: What are the chances that his change might make it into the boost date_time library? Is there some interest in this feature, if so I would provide a patch to update source and documentation to include the quarters as a new duration. Please let me know, Kind regards Thomas Lemm
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?
What are the chances that his change might make it into the boost date_time library?
Jeff Garland will need to answer that.
Is there some interest in this feature, if so I would provide a patch to update source and documentation to include the quarters as a new duration.
I think it would be a great addition. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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?
What are the chances that his change might make it into the boost date_time library?
Jeff Garland will need to answer that.
Is there some interest in this feature, if so I would provide a patch to update source and documentation to include the quarters as a new duration.
I think it would be a great addition.
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 than I don't thing you buy much more than simply writing const months quarters = months(3); 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. Jeff
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. 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. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Jeff Garland -
Stewart, Robert -
Thomas Lemm