Bug : date.h

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug : date.h

Gilbert Peffer
Hi,
There is a bug in the date::isLeap member function. The impact though is
minimal:

A year is a leap year if it is dividable by 4, EXCEPT if it is dividable by
100. Additionally, if it is dividable by 400, it is a leap year again.

Thus 1900 and 2100 are not leap years.

Although this won't possibly have an impact on any calculation, they are
things people (users) love to check out.

Gilbert




Reply | Threaded
Open this post in threaded view
|

Re: Bug : date.h

Luigi Ballabio-3
Hi all,

At 11:11 AM 12/21/00 +0100, Gilbert Peffer wrote:

>There is a bug in the date::isLeap member function. The impact though is
>minimal:
>
>A year is a leap year if it is dividable by 4, EXCEPT if it is dividable by
>100. Additionally, if it is dividable by 400, it is a leap year again.
>
>Thus 1900 and 2100 are not leap years.
>
>Although this won't possibly have an impact on any calculation, they are
>things people (users) love to check out.

Gilbert,
         sorry. We were aware of the thing, but we should have remembered
to document it.
We knew that 1900 and 2100 aren't leap years - the problem is, the two most
widely used spreadsheets around (Excel and Applix) both think that 1900 is.
Propagating such bug into our code was the quick and dirty method we chose
to correctly interpret the serial numbers passed by such spreadsheets in
view of a possible future Excel or Applix add-in based on QuantLib.
However, I now personally think that we should have the right thing into
our library, and move this correction into the external layer reading from
the spreadsheets - expecially since we don't have any such thing yet.

As usual, any ideas are welcome.

Bye for now,
                 Luigi