Talk:Day count convention
From Wikipedia, the free encyclopedia
I believe that there are errors in the 30/360 daycount description. I would suggest the following instead:
The number of days from M1/D1/Y1 to M2/D2/Y2 is computed according to the following procedure:
1. If D1 is 31, change D1 to 30.
2. If D2 is 31 and D1 is 30 or 31, then change D2 to 30.
3. If M1 is 2, and D1 is 28 (in a non-leap year) or 29, then change D1 to 30.
Then the number of days, N is:
N = 360(Y2 - Y1) + 30(M2 - M1) + (D2 - D1)
I have not seen the increase rule ever (for case where date2 is 31 and date1 is less than 30), and the February rule is confusingly placed as a variation. However, the current version has had so much effort put into it, maybe it is more common.
[edit] Day Adjust Rule
This article should like to an article on Day Adjust rules that tell you what to do on non-trading days.
I believe no article exists at the moment... but if someone knows about Modified following etc then it would be a good addition.
- You probably mean Date rolling, for which there is a page, but a wikilink would in dead be relevant. --Jarl Friis 07:43, 10 January 2007 (UTC)
[edit] Combining Pages
I saw the note about combining Day count convention and Interest rate basis. I think that's a very good idea. I think there's probably a lot of additional work needed as well. I'm more than happy to get the process started.
Are there others who have thought about this effort?
--Rudd73 21:29, 19 May 2007 (UTC)
Good idea. Go for it. MrRK 22:00, 30 May 2007 (UTC)
This is a heads-up that I'm starting the merge process. I'll do a straight merge first, and then look at extending the discussion. Looking ahead, we will probably want to do some level of merge/synchronization with the following topics:
--Rudd73 17:36, 11 June 2007 (UTC)
I've merged Interest rate basis into this page. I also performed some clean-up:
- Cited normative sources for the conventions, with the exception of 30E+/360. We still need one for that.
- Standardized the presentation, so that all conventions use the same format and match the way they are most commonly expressed by the defining agencies.
- Expanded the References and Further reading generally.
- Because of the consolidation of the past ten years, I did not include conventions which were used in the past but for which I could find no current usage. I'd suggest adding conventions only if a current usage with reference can be found.
- For the same reason, I pared back the information on how certain conventions are being used. This is in a state of flux. Also, some of them were incorrect.
I think we should merge Accrued interest into this page as well.
Date rolling needs some clean-up and references. I'm on the fence as to whether into should be merged in this page.
I'm looking forward to some feedback.
--Rudd73 22:19, 1 August 2007 (UTC)
[edit] The first rule for 30/360 US
An edit was made to change the month for D1 in the first rule from February to January. February indeed looks very odd. It means that the prior coupon payment date is a year before the settlement date of the trade. I've certainly never seen such a situation. I'm used to bonds paying two or four times a year. And I'm not used to seeing bonds using this convention paying interest at the end of the month.
But February is indeed the correct month. The normative reference (Mayle 1993) is unfortunately only available in a costly hard copy, but you can find the correct method in Accrued Interest & Yield Calculations and Determination of Holiday Calendars, p. 8 (though the format is slightly different; I used the original SIFMA rules in the page).
This is an interesting situation for a number of reasons. As mentioned in the References, the first two rules were added after the original rules (excluding the first two now given) had been used for years, for tens of thousands of securities. But the situation was encountered, so Jan Mayle added the new rules to cover it.
The second reason is how to interepret a reference giving the method without these first two rules (e.g., the ISDA). Are they establishing a different method or have they simply not bothered updating their documentation to cover a very rare situation? I lean towards the latter, barring any definitive resolution.
--Rudd73 01:35, 11 August 2007 (UTC)

