Based on
https://forums.mirc.com/ubbthreads.php/topics/263068/Re:_64_bit_time_values#Post263068

In case /timer will eventually be on the list of having 64 bit values, it may be easier to make these related changes at the same time...

1. Increasing the max possible delay. It appears that the longest delay-interval which doesn't trigger within 1 second is 2147483 seconds, a little longer than 24 days into the future:

//timera -m 1 $calc(2^31-1) echo -a test | echo -a $timer(a).secs

Since it appears timers translate N seconds into N*1000 milliseconds, it would need greater than 32 bits to extend the delay beyond 49 days.

2. Allow the time value to be in HH:nn[:ss] format. This should not cause backwards compatibility problem with current documented syntax which ignores the seconds in 12:34:56.

3. A switch to indicate that the time-value parameter is instead a delay defined in hours:minutes[:secs] from the current time (not a target clock time in the future), allowing a timer to trigger further away than 23:59 hrs in the future. i.e. using the new switch means 18:00:00 or 18:00 is 18 hours into the future, not 6pm. 36:00 would be 36 hours in the future from the timer's creation. I don't see the point in supporting days/weeks, if the hours are able to be much greater than 23. You could then use $duration( $calc(%future_ctime - $ctime) ,3)

4. Add a new switch so scripts can force HH:nn[:ss] to either
* not be interpreted as being less than 1 minute from now.
* not be interpreted as being 23:59 in the future.

This would make it much simpler to have a daily timer. It would also avoid problems of short intervals where $ctime rolled over to a new minute between where the script is calculating the desired trigger time and when the timer is launched. Usually when someone uses the HH:nn parameter, they are not intending it to be the current minute. Assuming switch -q:

timer -q1 00:00 1 0 = executes at the next midnight, except if the time is currently midnight it executes 24 hrs in the future instead of 1 second from now.

timer -q0 12:34 1 0 = if the timer launches at 12:34, the -q0 indicates the timer was intended to launch at 12:33 then trigger within a minute, not 23:59 in the future.

The below exaggerates the effect of a delay between when the HH:nn is calculated and when the timer is created.

Code:
alias testtimer {
  if ($asctime($ctime,s) < 54) { timer 1 $calc($v2 - $v1) testtimer | return }
  var %ctime $ctime , %a $asctime(%ctime,HH:nn)
  while ($asctime(%ctime,HH:nn) == $asctime($ctime,HH:nn)) {
    if (%t != $asctime($ctime,HH:nn:ss)) { var %t $v2 | echo 3 -a %t }
  }
  timertest %a 2 0 echo -ag timer launched at $asctime with trigger time %a
  echo -a time $timer(test).time future $timer(test).secs command $timer(test).com
}


5. A .prop like $timer().millisecs that gives the .secs in milliseconds. It appears that .secs currently takes a milliseconds value and chops any fraction, which means a value of 0 could be in the range of 1-999ms, and 1 could be anywhere from 1000 to 1999ms. This next line sometimes shows 10, but often shows 9 immediately after creation:

Code:
//timertest 1 10 noop | echo -a $timer(test).secs


It makes sense that -h high resolution MMT timers should have access to better resolution for .secs than having 1-999 milliseconds subtracted from the answer.

6. A .prop that indicates whether the .delay was created in millisecs using the -m or -h switches. Even though "/timer" shows whether a timer's delay is in millisec, a script can't tell whether an active timer was created with

timer -m 1 5000 noop
or
timer 1 5000 noop