/timer trigger on a set time AND date - mIRC Discussion Forums

Hi there,
It would be useful if you could add a time AND date to a /timer rather then just a time to trigger.

Thanks

Ninko

It would be also cool if you could make timers persistant without having an on *:START: reinforcing them.

It's easy to calculate the amount of seconds between two points of time with scripting, so in my opinion this would be added bloat. If anything, I'd propose the addition of a new switch '-u' to /timer, which allows you specify a CTIME value. But once again, this is easily achievable in scripting.

Also in my opinion, having persistent timers would be a waste. Timers are for scripting, and ON START *is* scripting. It's not a trivial chore or challenge to start a timer with ON START, nor does it come at any realistic cost whatsoever. If ON START didn't exist, I'd endorse this. But unfortunately it's more than completely feasible to achieve the same outcome using the current method of persistent timers.

Seconding the -u flag for /timer. :3

Code:

//timer 1 $calc($ctime(01/01/2009 00:00) - $ctime) amsg HAPPY NEW YEAR!!

The problem with that hixxy is I find it tends to lose sync with time after a long period finally triggering at the wrong time, hence the trigger on set time and date.

Ninko

So instead of filing a feature suggestion, you should of filed a bug report about the desync so we could of examined your code...

But as far as /timers are concerned, if you need pin point accuracy then don't use mIRC and mSL for projects. As plain and simple as it gets, mIRC is an IRC client and IRC isn't a time critical environment (spare me the TS debate), nor developed on that model. So why should the clients move towards that direction?

To solve the desync issue however, I'd write my own time scheduler using an Object Oriented model and choose whatever format I wanted for representing the date/time/millisecond reference, and perhaps use a pre-fetch mechanism that schedules an exclusive check a minute before it's suppose to trigger just to verify its on time, then make any corrections and schedule yet another exclusive timer.

A feature suggestion for a datetime trigger on a timer would not mean it would necessarily be any more accurate than hixxy's suggestion. In fact, I bet the implementation would be the C equivalent of that code. Either bug report it as mentioned or follow the scriptable suggestion below:

If synchronization is an issue, run a shorter timer that verifies the current date has been reached at which point you can set the timed timer, or do something similar once you're within N minutes of the intended trigger time.

Code:

alias cron.delay { return 30 }
alias cron {
  if ($calc($1 - $ctime - $3) < 300) { 
    .timer 1 $v1 $4-
  }
  else {
    var %delta = $calc($ctime - ($2 + $cron.delay))
    .timerCRON 1 $cron.delay cron $1 $ctime $calc($3 + %delta) $4-
  }
}
alias cronstart { cron $1 $ctime $cron.delay $2- }

/cronstart $ctime(1/1/2009 0:00) msg #somechan happy new year

The code above uses a delta accumulator to keep track of how far off the timer has wandered and adds this adjustment value to the final timer. This may not even be needed.

It was just a feature suggestion to make it abit more flexible people, its either taken on board or it aint.

Ninko

The situation isn't about being a bad suggestion, it's about the principal of the problem you presented in the original post. You claim the timer mechanism is unreliable, however your solution is to use the same unreliable function of the program, but which accepts an additional date input. You're contradicting yourself in this suggestion, which has nothing to do about being flexible or not. My suggestion of the addition of accepting CTIME values is about flexibility, however like others have pointed out it's pointless because you're not solving the problem itself -- which is easily avoided by currently provided scriptable solutions.