It was broken in ISR8 - something changed which meant that the order of the arguments was different from what it said (if you specify the high value then the low value, then it should be 10 90 as the first threshold is 10 percent of the way between the high and the low, and the second threshold is 90 percent between the high and the low).
It was fixed in ISR12 (may have been ISR11, but I see an integration notice for ISR12 too). This was as a result of CCR 972729. There's another related CCR because we weren't really happy about the fact that riseTime and fallTime would actually detect the opposite if the arguments were specified the other way around - they are essentially doing the same thing at the end of the day. I believe it's more clearly documented from ISR12 onwards (I didn't check just now as I'm on vacation today and only taking a brief look).
In the affected versions, you could use the attached code. Use:
(the file is password encrypted, and the second argument is the password). Only use this in IC615 ISR8-ISR11, after which it is unnecessary.