As fixes go, this has obvious limitations.  The remaining time before overflow is only going to get smaller: in 23 years time, you'll have no space left for what you can add here without overflow; how close before that do we need to come up with a replacement for this ?  If the 60*60*24*365*10 constant here is simply added to the time (not scaled by any multiplier) then we've got 13 years - that'll do for now - but we have to think about what we plan to do about this in future !

What are the actual semantics of the parameters here ?  Why is 10 years ahead an acceptable margin here ?
Also: the number of seconds in an average (over 400 years of the Gregorian calendar) year is 773 * 7 * 8 * 729, in which 729 is 9**3, so 8*729 is 18**3; but ignoring the corrections for centuries to use 365.25 days is adequate in practice (given that you're already not looking 23 years ahead) and gives 487 * 81 * 800 seconds as average.  Even if we're going to use the crude 365*24*60*60 approximation, we should at least package it in a const int YEAR for clarity.