Matthew Persico wrote:
2) All business dates will have no time component. All decrements and
increments of business dates will be a number of days - I don't think
there is a concept of business weeks or months...
I relplied
Absolutely disagree on this point. You have to have finer control than
days. If a project is going to take 100 man-hours and you have 7 people
working on it, you need to be able to ... [snip]
To which you said:
When I say business date in the US, I'm thinking in terms of dates on
which financial transactions are able to be executed or settled. Time
is irrelevant: for example, if the trade executes on a Friday, it
cannot settle on Sat or Sun because the are not business days. Hours
are irrelevant.
I'm not sure about other people, but I don't want the Business namespace
taken up with a calendar that only suits YOUR purpose. There's a large
world outside the US, and there's a lot of people who would want a lot
finer control than 'days'. Seems that your needs are merely an
application of DateTime::Calendar::Business rather than the purpose of
such a module.
If I were writing an object to handle your examples below, I'd call it
DateTime::Calendar::Man (as in man-hours, man-days, man-weeks, etc,
with apologies to the other half of the human race...)
No, they're business hours. That's what people call them. Man hours are
something else entirely. The company I work for is open for 8 business
hours today, but there's 12 staff so it's open for 12 * 8 man-hours.
which would need a holiday calendar attached to it in some way (much
as my DateTime::Business would) to get the math right.
Agreed. We need DateTime::Calendar::PublicHolidays and
DateTime::Calendar::PublicHolidays::@locales
Between your comments and those of [EMAIL PROTECTED] prior to yours, I
am starting to think that the only "right" way to do this is to create
the calendar as a separate entity and feed it to DateTime instead of
trying to create Yet Another Sub Class of DateTime. The only thing I
have to account for in my world is setting time to 00:00
Calendars are normally separate objects as they require a lot different
date-math than a Gregorian date
In Australia, the tax year start on July 1st and finishes on June 30th
and so truncating to year would have to return a July 1st date. In the
states I believe it's April 19th or some such.
In the US, April 15 is the date by which you have to file your tax
return for the previous year. The tax year is Jan 1 through Dec. 31
for all personal taxes. I don't know the effect on taxes for a
business with a fiscal year != physical year. Most file quarterly
anyway - the end of year may only affect when any refunds are actually
refunded to a business.
A physical year is merely the time it take for the earth to orbit the
sun. January 1 is merely a moment in the orbit that we choose to
increase the gregorian calendar. As I've said, the Australian Financial
Year goes from July 1 to June 30 on the Gregorian Calendar. You'd need
to account for that. (And for other countries with similar situations --
I know they're out there)
> [snip]
Aside from the use of hours, which I don't need,
If you're going to write publicly available modules rather than
solutions you keep in-house, you need to drop the concept of 'I don't
need'. Once you release DateTime::Calendar::Business, the namespace is
taken (OK, so CPAN will let me release the same thing .. but it confuses
the community). If you insist on releasing this version of a Business
calendar, please call it DateTime::Calendar::Business::USDaysOnly or
some other such.
Cheers!
Rick Measham
