Extending ctime to represent dates from 1900 doesn't mean ctime would need to be 'reset' to use 0 as 1 Jan 00:00 1900 UTC. There's nothing about ctime that says it can only represent times after the UNIX epoch, there are many many implementations that already handle negative values correctly.
While mIRC currently uses a 32-bit signed integer, which wouldn't quite reach back to 1900, there's absolutely nothing stopping mIRC implementing ctime using a 64-bit signed integer and correcly handling negative values to future-proof and past-proof $ctime() once and for all (well, until 292000000000 AD at least).
