Add more functionality to Calendars
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
JQuantLib |
New
|
Medium
|
Unassigned |
Bug Description
> Mark Breman wrote:
> > Hello Richard,
> >
> > I had a look at JQuantLib's calendars last spring when I started work
> > on the AQ calendars and there was a thread on the AQ mailinglist about
> > the two projects. If I remember correctly you were busy working on a
> > release for the calendars back then...
> >
> > Looking at the source code of the JQuantLib calendars now it's obvious
> > that there is a lot of overlap but also some differences in modeling
> > this domain. I must say I really like parts of the approach you took.
> > On the other hand I think you are still facing the same issues we are
> > i.e.:
> > - support for early closing days (we support this now)
> > - international exchanges with mixed holidays for (groups of) instruments
> > - calendars for specific (group of) instruments (ex-dividend date,
> > share holder meeting, expiration dates etc.)
> > - calendars for clearing data
> > - open/closing for exchanges with floor-trading (i.e. multiple sessions)
> >
> > Do you have plans for addressing these issues in the future? If so, in
> > what direction are you thinking.
> >
> > I must say that I am really in favor of integrating both projects as
> > there is going to be a lot of the same work done on both projects in
> > the future (not only the calendars), and we could make a real effort
> > together.
>
> If there is some activity put into that direction, then move it all over
> to this server. Here we have a full root server that allows hosting many
> more domains and projects.
=============
Relationships
=============
related to http://
related to http://
When presenting JQuantLib to user groups, they observe that Joda Time should be adopted. At the moment, we mimic the interfaces defined by QuantLib (which are absolutely unrelated to Joda Time).
There's a possibility that Date and Calendar related classes become do diverge from QuantLib/C++ API due to user requirements.
On the other hand, the migration path from QuantLib to JQuantLib must be as smooth as possible, so, there should be close resemblance between APIs.
It's not clear at the moment how we could provide a common solution for these 2 requirements.