mIRC Home    About    Download    Register    News    Help

Print Thread
#146133 31/03/06 02:24 PM
Joined: Jul 2005
Posts: 51
P
Babel fish
OP Offline
Babel fish
P
Joined: Jul 2005
Posts: 51
Quote:

$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?

#146134 31/03/06 02:28 PM
Joined: Feb 2006
Posts: 164
V
Vogon poet
Offline
Vogon poet
V
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.

#146135 31/03/06 02:58 PM
Joined: Oct 2005
Posts: 1,741
G
Hoopy frood
Offline
Hoopy frood
G
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.
#146136 31/03/06 04:41 PM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
omg it well be the Y2K+38 bug! :-)

#146137 01/04/06 03:01 PM
Joined: Nov 2004
Posts: 842
Hoopy frood
Offline
Hoopy frood
Joined: Nov 2004
Posts: 842
This is prolly the best you could do for now ...

Code:
/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?
#146138 01/04/06 06:32 PM
Joined: Dec 2002
Posts: 2,962
S
Hoopy frood
Offline
Hoopy frood
S
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.
#146139 04/04/06 01:29 PM
Joined: Jan 2003
Posts: 1,063
D
Hoopy frood
Offline
Hoopy frood
D
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!
#146140 04/04/06 03:20 PM
Joined: Sep 2005
Posts: 2,881
H
Hoopy frood
Offline
Hoopy frood
H
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.

#146141 08/04/06 09:16 AM
Joined: Sep 2003
Posts: 4,230
D
Hoopy frood
Offline
Hoopy frood
D
Joined: Sep 2003
Posts: 4,230
too right, that would annoy me greatly!


Link Copied to Clipboard