Yes, Sergey. This is a nice technique for moving the point of wrapping from midnight to the time 24 hours after the start, which is sufficient for many cases. I am using a slightly different formulation of it myself:

#define SECONDS_PER_DAY  (24 * 60 * 60)

nStartSecs = seconds()
...
nElapsed = mod(SECONDS_PER_DAY + seconds() - m.nStartSecs, SECONDS_PER_DAY)

For longer time intervals one can keep the corresponding DATETIME() values in addition to the seconds to make a more universal timer that is accurate for short intervals and does not fail on longer ones:

tStartTime = datetime()
nStartSecs = seconds()
...
nEndSecs = seconds()
nElapsed = datetime() - m.tStartTime
if m.nElapsed < SECONDS_PER_DAY
   nElapsed = mod(SECONDS_PER_DAY + m.nEndSecs - m.nStartSecs, SECONDS_PER_DAY)
endif

But this kludgery is only necessary because
- DATETIME() throws precision away by rounding to full seconds
- SECONDS() retains the original precision but wraps at midnight
Yes, we need both sub-second precision (for screen updating) and a range extending to one or more days because some jobs can take that long (bulk image processing/OCR).