Wow guys. Several problems in both responses. Sorry if that sounds harshly critical off the bat, but I'll explain.
FroggieDaFrog: The intended design is to trigger at clock events and not arbitrarily. Yes: the 'everyfifteen' event is desired to fire at 0,15,30,45 ... and not 7,22,37,52. That's simply what I want. Like a cron.
As such, I'm using HH:nn timers because they are accurate to the second (the top of the minute), and do not trigger somewhere arbitrarily in the middle of the minute. Eg: everyfifteen always triggers at 00:15:00.000 (unless there is heavy CPU load) and not 00:15:49.362. That's simply what I want, and mIRC is quite capable in that area without any craziness. It pairs well with logged events in this way.
The main problem is, you can't just set an HH:nn timer every minute without the chance of the system clock skipping forward or backwards and missing that minute. If that HH:nn never comes, the whole operation halts until the following day. Thus, the secondary assurance timer is necessary to keep the main timer on task in case of time change or clock adjustments.
Ouims: /timer HH:nn 1 0 versus /timer 0 60
When specifying an hour:minute timer, that timer triggers precisely after the clock's minute changes. The -m and -h switches for /timer only specify the resolution of the delay parameter and has no effect on HH:nn 1 0 timers, since there is no delay to speak of. 0 is equivalent to 1ms with or without -h or -m. Adding -h does nothing in your example.
The rest of your post is pretty hung up on this idea about -h and that I'm somehow hung up on more accuracy. I'm not though, I never was. I'm hung up on how HH:nn timers don't have any consideration that HH:nn might, rather will, be skipped over regularly when there are time changes and adjustments to the system clock.
I recommend you try this script before commenting further.
