Forums Bug Reports [7.25] $ctime/$asctime and the Y2K38 limit

I couldn't help notice this.

$asctime(2147483646) > Tue Jan 19 03:14:06 2038
$asctime(2147483647) > Tue Jan 19 03:14:07 2038

But...

$ctime(Tue Jan 19 03:14:06 2038) > 2147483646
$ctime(Tue Jan 19 03:14:07 2038) > insufficient parameters

I believe this is due to mIRC being a 32-bit application (even if run on a 64-bit OS). The underlying timecounter is limited to 31 bits of data (the 32nd bit is used for signage, which plays no role with regards to a timecounter but idiot programmers of OSes and libraries chose to use a signed 32-bit number rather than unsigned), which happens to be the number of seconds between January 1st 1970 @ 00:00:00 and January 19th 2038 @ 03:14:07.

Full details are available on Wikipedia. Read (do not skim) "Solutions":

http://en.wikipedia.org/wiki/Year_2038_problem

There's no real way for mIRC to solve this other than to provide native 64-bit builds. Those of us using 32-bit OSes (regardless if our CPUs support 64-bit numbers or not -- the limitation is not there), or those running 32-bit builds of mIRC on a 64-bit OS, will just have to deal with it.

mIRC can start using 64-bit time_t values without becoming a 64-bit application. This wouldn't be that difficult to fix at all.

It looks like Windows has solved this in quite a different way (see "Remarks", and read the entire thing) than *IX platforms have. So you are absolutely 100% correct and I am wrong.

Though it's still quite a mess. As the poster there indicates at the bottom of his post, it's not always as easy as changing the declaration type; anything other code that uses hard-coded 32-bit numbers for time (e.g. not using time_t but instead using uint32_t or equivalent) would need to be changed, and that doesn't include any actual code that is written to assume the maximum value is 0x7fffffff. I can't comment on that part of mIRC (I have no visibility into the source, obviously).

I plan to implement this at some point, however, as mentioned, it would take more work than just updating the declarations. There are a number of places where time values are stored/manipulated in general use 32bit variables, which means I would have to track down every such use to update it.

When I start working on a 64bit version of mIRC (which I have attempted once or twice before - before realizing what a huge job it was!) robust declarations for 64bit variables will be needed and this will include time values. It will take quite a bit of work and testing as a 64bit version will require hundreds of codes changes.