|
|
|
|
Joined: Jul 2005
Posts: 51
Babel fish
|
OP
Babel fish
Joined: Jul 2005
Posts: 51 |
$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?
|
|
|
|
|
Joined: Feb 2006
Posts: 164
Vogon poet
|
|
Vogon poet
Joined: Feb 2006
Posts: 164 |
Not really, since that's the date of the the Unix Epoch. I couldn't see a need for this.
|
|
|
|
|
Joined: Oct 2005
Posts: 1,741
Hoopy frood
|
|
Hoopy frood
Joined: Oct 2005
Posts: 1,741 |
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
Last edited by genius_at_work; 31/03/06 03:10 PM.
|
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
omg it well be the Y2K+38 bug! :-)
|
|
|
|
|
Joined: Nov 2004
Posts: 842
Hoopy frood
|
|
Hoopy frood
Joined: Nov 2004
Posts: 842 |
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
Last edited by Jigsy; 01/04/06 04:19 PM.
What do you do at the end of the world? Are you busy? Will you save us?
|
|
|
|
|
Joined: Dec 2002
Posts: 2,962
Hoopy frood
|
|
Hoopy frood
Joined: Dec 2002
Posts: 2,962 |
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).
Spelling mistakes, grammatical errors, and stupid comments are intentional.
|
|
|
|
|
Joined: Jan 2003
Posts: 1,063
Hoopy frood
|
|
Hoopy frood
Joined: Jan 2003
Posts: 1,063 |
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...
If it ain't broken, don't fix it!
|
|
|
|
|
Joined: Sep 2005
Posts: 2,881
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2005
Posts: 2,881 |
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.
|
|
|
|
|
Joined: Sep 2003
Posts: 4,230
Hoopy frood
|
|
Hoopy frood
Joined: Sep 2003
Posts: 4,230 |
too right, that would annoy me greatly!
|
|
|
|
|
|
|
