Very interesting post.
However, I am interested in knowing what the differences are between
the different calendars.
Are the variables that I mentioned in a previous post sufficient or
have the exchanges done something exceedingly odd in the past.
Why can't you tell what the TOKYO calendar will be until Jan 1st?
I assume that the differences between the US exchange calendars
basically boil down to:
- Different holidays
- Different opening hours
- Different week numbering scheme
In which case DateTime::Sets of holidays and hours will be enough to
handle the first two cases, and some flag will handle the different
week numbers.
I intend to make some convenience factories that will make some
standard holidays (e.g. US federal holidays, each state's holidays,
special bank holidays, etc.), I will worry about that later though.
-ben
On Thu, Jun 05, 2003 at 01:32:14PM -0700, Brad Hughes wrote:
> Ben Bennett wrote:
> >Okay so what should a business date module be able to do?
>
> What is a "business day?"
>
> A quick glance at our internal date modules reveals over 40 different
> "business day" calendars. You've got, for example, the NYSE, NASDAQ,
> AMEX, CBOE, PHIL, Midwest, and Pacific Stock Exchanges, which
> *currently* use the same calendar, though they haven't always.
> And that doesn't include the NYFE and the CBOE and KCBT and the
> other Futures and Commodity exchanges. And even though they may
> use the same calendar, currently, they're open different hours.
>
> And that's just the U.S. You also have Tokyo, Osaka, Nagoya,
> Hong Kong, Toronto, Paris, Zurich, Frankfort, and at least 3 flavors
> of London market calendars.
>
> Oh, and in the U.S. there's a separate Bank Holiday calendar, which
> is different than the Federal Holiday calendar. And I believe each
> state in the U.S. has its own notion of "business" calendars (did you
> know that in Texas in January you can celebrate either Martin Luther
> King Day or Confederate Heroes Day; they were merged when Texas
> agreed to observe MLK Day).
>
> (As an aside, this plethora of possible calendars was the reason I
> objected to DT:: using ::Calendar to refer to how dates were described
> (Gregorian, Mayan, Ancient Sikh Moon, etc) instead of what they represent
> (NYSE, BANK, FEDERAL, etc) in an earlier ignored post. It just seems to
> me that ::Calendar is too perfect a word to waste on something that will
> default to Gregorian in the vast majority of cases instead of available
> for what I believe will be the more common need to describe different
> "business day" calendars.)
>
> In any case, my suggestion is, for each calendar, take a scalar where
>
> 1) each bit represents a calendar day, starting from some start date
> (data is available for the NYSE going back to 1885, when the NYSE
> had a special closing for the funeral of Ulysses S. Grant);
> 2) a bit is 1 if that day is a valid day for that calendar;
> 3) the scalar is uuencoded and stuck in a __DATA__ section.
>
> The tough part is keeping these uuencoded bitstrings accurate, one for
> each calendar. You can know pretty well what the BANK or NYSE
> calendar will be for some time in the future, except for things like
> special closings for a president's funeral or Sep 11. TOKYO is another
> matter; sometimes you're not sure what a year's going to look like
> until Jan 1.
>
> Perhaps datetime.perl.org could be the repository of a "master" copy
> which changes when need be, and some mechanism to verify and update
> a local copy be made available. This doesn't work well for sites
> isolated from the net, but they'll cope.
>
> brad
