Logged In: YES 
user_id=6405

Gawd the sf tracker is horrible. I'm sure your original text wasn't so badly 
formatted :) 
 
The addition / subtraction code definitely needs some attention, thanks for 
pointing that out. Overflows in time calculations should be handled, up to 
the day level. Day overflow cannot be handled reasonably into months 
without some programmer intervention. Certainly not through some default 
ratio like 30.44 - that would produce strange results indeed. Off the top of 
my head, I can't think of a situation where a user would _want_ day overflow 
to affect months. 
 
I agree with your comment about time representation ambiguity. 
 
Division of intervals is a strange one, and I'm not sure it's so common as to 
require the major change to the way intervals work to support. I don't 
believe that month intervals may be dismissed so easily. They're a useful 
quantity to be able to define. Converting months into some number of days 
will not do. Perhaps an alternative is to be able to extract the number of 
seconds for an interval (supplying the number of days/month (default 
30.44) and days/year (default 365.4)) which may then be manipulated by 
division etc. and supplied back to the interval code (again with the 
conversion ratios). This then makes it explicit that funny business is going 
on with conversion ratios, and the current internal representation and 
behaviour is unaltered (short of the addition/subtration bugs ;).