$ctime(text)
Returns the number of seconds elapsed since 00:00:00 GMT, January 1, 1970 based on the date that you specify.
It would be nice to extend $ctime to 1900, what do you think?
Not really, since that's the date of the the Unix Epoch. I couldn't see a need for this.
You can't just "extend" ctime (32-bit time) back farther. You'd have to go alter almost every computer on the face of the planet. 32-bit ctime will "end" at 18 Jan 2038 19:14:07. That is when all 31 numerical bits are 1s (1 bit is the sign bit, and is unused). I believe there is a 64-bit version in the works somewhere to allow ctime to continue working past its 32-bit roll-over point.
-genius_at_work
omg it well be the Y2K+38 bug! :-)
This is prolly the best you could do for now ...
/vtime {
var %x = 1900, %y = 31622400
while (%x < 1970) {
inc %x 1
if ($numtok($calc(%x / 4),46) >= 2) {
var %y = %y + 31536000
}
else { var %y = %y + 31622400 }
}
var %y = %y + $ctime
return %y
}
I'm not sure if thats actually correct though ...
If I can be bothered I'll try improve it
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).
win32 API actually has a __int64 struct (which is simply a struct consisting out of 2 32 bit int's) which could be used for this...
I don't think it's worth the bother then. Having to change the code again in 291999997994 years will be a pain in the ass.
too right, that would annoy me greatly!