Forums Bug Reports /timer <time> and $timer(n/name).secs

if i use /timer 10:00 1 60 or so and then //echo -a $timer(1).secs the time reduces from the moment i start the timer and not at 10:00 (ok, the timer works correctly, but $timer returns an invalid output)

I don't know if I'd call it an invalid output, but rather an incorrect or inaccurate output, however, I see what you mean.
Based upon the information in the help file, I would've thought that it would return the number of seconds between the current time and the execution time (which for your example would be 10:01 am)

If /timer 10:00 1 60 was issued at 9:30, then //echo -a $timer(1).secs was issued at 9:35 am, I would've thought it would return 1560, not 0.

I would've thought that 0 would only be returned at 10:01

yeah i had issues with timers a couple of weeks back. Heres an example

/timertest 10:30 0 5 dostuff

10:29:57 timer.secs 0
10:29:58 timer.secs 0
10:29:59 timer.secs 0
10:30:00 timer.secs 5 (repeated every 5 seconds)

i.e. the timer is activated at the time set and goes on to count the repetitions and intervals FROM THEN.

now if this was set up at 10:25:00 the strange behaviour exists....

10:25:00 timer.secs 5
10:25:01 timer.secs 4
10:25:02 timer.secs 3
10:25:03 timer.secs 2
10:25:04 timer.secs 1
10:25:05 timer.secs 0 (where it would remain until 10:30:00)

In my opinion this is definately a bug. I have a script that uses somethign like

if $timer(timer).secs { show $v1 }
else { show $timer(timer).time }

which gives the buggy behaviour on setting, which could theoretically run into the $timer().time activation should the interval be longer on setting than the time until activated.

It's an overlap I dont like, I know that. lol

btk

I get what your saying but .secs doesnt quite work that way. $timer().secs returns the time untill the next execution but only after the timer is first initiated and in that respect it works perfectly. So for "/timerlol 10:00 0 5 echo -a cool" $timer().secs will return 4 at 10:00:01. The 0 it returns before this is very handy as this tells you that the timer is not yet initiated. Once initiated $timer().secs is never 0.

So .secs is not bugging however the feature your looking for makes for a nice feature suggestion.

If $timer().secs always returned 0 until it reached the specified <time> given then it could be argued that it was intentional behaviour. But that's not the case. When the timer is first set $timer().secs is set to the <interval> and counts down immediately to 0, where it remains, until resetting back to <interval> again once <time> is reached and counting down as expected.

Personally I tink $timer().secs should return <interval> until it starts counting down and a new $timer().state should return paused/active/awaiting top show the actual state it's in.

Ahh i missed that

* just tacking on to the last message *

Its not overly hard to see if a timer is counting down .secs or set to go off at a specificed time .time.

$timer().time now if that has a value $timer().secs is invalid, i say invalid becuase $timer().secs well actually count down the delay on a time set timer when its first created (did that make sence?)
ex //timerxxx 12:00 2 15 echo -a BLAH | echo -a $time(xxx).secs
15
followed in a few secs by //echo -a $time(xxx).secs
11
right down to 0 at which it holds untill 12:00, if it reaches 12:00 before 0 it resets to the 15 of the delay again.

So check $timer().time if its got something in it its a time delayed timer, if not check $timer().secs if its NOT 0 (zero) then the timer is "likely" not paused and is running down to go off.

I said "likely" becuase timers do a wierd thing when u /timer -p them, they pause at when there ment to go off. Not when you -p'ed them, ie: they continue to count down, then when they reach 0 they sit there untill resumed, then go off at the next timer check (start of next second), AND this I would call a bug!

yeah that's definately a bug, pause means pause now. It doesnt mean just dont do anything next time. In my mind pausing a timer should pause .secs AND .time should not activate(the timer is paused so stops counting down to $timer().time.)

This relates back to the last thing, i feel that $timer().secs should return the seconds left until $timer().time (if that param exists in the timer). once $timer().time has been reached it should then do $timer().secs on the intervals.

btk

;usage $_timer.secs(timername)
;returns the secs to a timer event, be that the next timer repitition or the start of time of a HH:NN timer
alias _timer.secs { return $iif(($len($1) && $timer($1)), $iif( $timer($1).time , $calc(($ctime($date $v1) - $ctime + 86400) % 86400) , $timer($1).secs) ) }

or

;usage $_timer.secs(timername)
;returns the secs to a timer event, being when the timers commands well be run
alias _timer.secs2 { return $iif(($len($1) && $timer($1)), $iif( $timer($1).time , $calc((($ctime($date $v1) - $ctime + 86400) % 86400) + ($timer($1).delay / $iif($timer($1).mmt,1000,1))) , $timer($1).secs) ) }


The 2nd one adds to the Now time to HH:NN time the delay time of the timer as well, once it reached the HH:NN time
ie:
At 11:00:00 u set off /timer 12:00 1 88 echo BLAH
method 1 returns 3600
method 2 returns 3688 (adds the 88 delay before the first timer command goes off

WARNING ON METHOD2
* please note due to the /timer -m option not setting the $timer().mmt flag to true the results if checking a HH:NN set timer that is also a /timer -m timer well produce incorrect results.
ie: At 11:00:00 u set off /timer -m 12:00 1 88000 echo BLAH
method 1 returns 3600
method 2 returns 91600 (adds the 88000 delay before the first timer command goes off instead of 88000 / 1000 = 88, no method to fix as i cant detect if timer is -m or not)

Thanks this has been fixed for the next version.