This change could be coordinated with the
https://forums.mirc.com/ubbthreads.php/topics/267046/improve-ticks-accuracy or
https://forums.mirc.com/ubbthreads.php/topics/266944/ctimems-with-millisecond-decimal-value request.
In addition, the .mtimeMS, or whatever it will be called, could also be expanded to support the new date range which goes back to 1601. If a file's timestamp is changed to be "Jan 1 1970 12:00:00am", the returned value for .mtime or .ctime is $calc( $daylight + $timestamp). However, setting the timestamp as "Dec 31, 1969 11:59:59" and earlier always returns -1, the same as happens for timestamps 1/1/3001 midnight and later - even though $asctime supports years 1601-9999.
Windows has a SystemTimeAsFiletime function which returns a signed int64 with a value equivalent to these millisecond file timestamps. When I call that function from a .dll, it seems to return values changing in increments of 10000, which would be a resolution in millisecs. The QueryPerformanceCounter function can return a benchmarking value with a narrower and more variable increment, but it's also not consistent across Windows versions. Beginning Win10 around release 1809, the QPC value increments 10 million per second for everyone, while earlier versions of Win10 and earlier Windows versions increased per second at a rate somewhere around one thousandth of the cpu's gigahertz speed.
