looks like the beta 907 crash was due to $asctime(N) using N which is either too large positive or too large negative.
Thanks, I was able to reproduce this. This is due to the strftime() function in the CRT which needs to be used even with "/timeapi on" because there is no API replacement for it. Unfortunately, it has the same issue as other CRT functions; it performs invalid parameter checks and terminates an application if parameters aren't within the range it expects, instead of just returning an error to the caller.
One solution would be to disable invalid parameter asserts in the CRT using _set_invalid_parameter_handler(). But this would affect all CRT function calls in the release version. On the one hand, this would prevent mIRC from crashing in such situations. On the other hand, we wouldn't know that there was an error.
That said, I am only able to get it to crash if the time value is beyond year 9999. If the time value is below year 1601, no crash occurs here; localtime() adjusts the time value to a minimum of 1601. So even with the invalid parameter handler, it would not be possible to detect if a date less than 1601 was supplied.
So the only way to prevent/detect errors with strftime() seems to be check if the tm structure being passed to strftime() contains a date range close to the minimum 1601/maximum 9999 dates and, if so, to not call strftime(). Not a great solution but I can't think of any other options at this point. This will be in the next version.
