it would help to have a short bit of code to demo the problem
in the timer source on line 232 you'll find the calc for the next recurrence time:
-- this means "next scheduled time will be: current scheduled time plus interval" (comment added)
local fireTime = entry._time + entry._delay
and note that there's no dependence on system time at this point, so it SHOULD auto-correct itself (to the resolution of frame events)
ie, if it's a one second interval, and the first call occurred at (fe) system time 1234, then next is 2234, then 3234, then 4234, etc.
(iow, it would be a major blunder if that line had been written as "local fireTime = system.getTimer() + entry._delay", but it's not)
actual execution time (vs scheduled execution time) is of course subject to the frame rate resolution, so figure a +/-frame's worth of "slop" for the actual callback, but you should NOT be seeing an overall trend of increasing interval "lag". (fe 1000ms interval, then 1030ms, then 1060ms, then 1090ms, then 1120ms, etc)