Well I felt i had to tell the truth, i saw the first one the
(19:39:53) ONE
(19:39:53) TWO
And i felt I knew what this was, its when the alias/commands executed to create the timers cross over a clock tick boundry, so the /timer 1 1 and timer 1 2 both go off on the next clock tick, same occurs if you delay mirc being able to process commands for multiple seconds, a set of timers set 1 second apart well all trip together.
(by clock tick im refering to a 12:00:00 to 12:00:01 change)
This below I now realise I miss understood (now that you pointed it out) and thought this was what had been reported to you(20:01:28) ONE
(20:01:31) FOUR
(20:01:31) FIVE
and the one below that was you replying about using the -h on a timer (which looks like something else running took a few seconds to complete, with a gap that size)
(20:04:08) FOUR
(20:04:13) FIVE
--
The reason i came to that conclusion is becuase, I ran your command, and not once could i produce results that showed a jumped second, besides the odd inital one never a
(20:01:31) FOUR
(20:01:31) FIVE
type event. I even added fields such as Querty's $!ticks to see about the displacement of time between timers, each one was 1000ms (excepting those odd inital ones)
I also got an identical last 3 digits but mine were different from Querty's, being 082, these always being the same and well different from the last 3 digits of $ticks at the timer creation, enforces how i understand timers to be dealt with , however I think there maybe some code in there to control how those first seconds are dealt with
example
//.timer 3 1 echo -at $ticks : $!ticks : $!calc( $!ticks - $ticks ) : $!ctimems
[09:40:42] 719850505 : 719851442 : 937 : 1122327642.235
[09:40:43] 719850505 : 719852442 : 1937 : 1122327643.235
[09:40:44] 719850505 : 719853442 : 2937 : 1122327644.235
//.timer 3 1 echo -at $ticks : $!ticks : $!calc( $!ticks - $ticks ) : $!ctimems
[09:40:51] 719859114 : 719860442 : 1328 : 1122327651.235
[09:40:52] 719859114 : 719861442 : 2328 : 1122327652.235
[09:40:53] 719859114 : 719862442 : 3328 : 1122327653.235
The first time the timer goes off slightly under 1 second, the next time its over 1 second, I have seen it as low as 908 and as high as 1804, I assume there must be some code in there that says something like if 900 or less ticks since creation then dont give it the first second count.
Something else I also used was a custom identifier $ctimems which gives $ctime plus a milliseconds as a decimal, i confirmed this was goiving accurate results before use. You well notice the time the times went off was not anywheer near the actual $time tick over of a second, but did seem to be at a constant second tick over point.
--- please read ---
hmmmmm ok i written what i wrote above, not really trying to disprove you, just saying what i found, and now i found how to produce your results so i take back the (now italic above)
and not once could i produce results that showed a jumped second. If i take the mirc online and have several other events/timers running i can produce the same effect. While offline everything runs smooth (then again all my other timers stop also)
