An asteroid will kill us in 2036

Not sure what that has to do with the topic though
But lets run with it..
I thoughly enjoyed the danial being a prior subplot
On topic:
I'll be 51 assuming I'm alive then.
I cant imagine being 51..

 

New data on this asteroid now puts it firmly out of range. Bring on the next highly unlikely, but panic inducing alarmist world destroyer!

 

2036 is close to 2038, which is famous for its '2038 problem' where all computers will stop working ( or something like that), so I guess the 2030s are gonna be bringing lots of trouble.

 

Someone didn't read the article.

 

Is that 2038 problem anything like the y2k bug? I'm curious because this is the first I've heard of it.

I'm going to test this experimentally. I'm off to set my pc's year calander to 2038. If I'm not back in 10 minutes, you'll know we're all doomed.

 

Musta missed that part
However, it seems Apothis is very much alive and seekng revenge on the Tau'ri!

 

Yes. The time_t type in C is a signed int, and it's used to store a date/time as seconds since 1 jan 1970. 00:00:00 GMT. A signed int is typically 32 bit, and the largest value it can store is then 2 147 483 647. That means that it will wrap at 19 Jan 2038 03:14:07 GMT.

googleoogleoogle ... http://pw1.netcom.com/~rogermw/Y2038.html

 

Better hope you ditch your FAT file system by then ( I'm pretty sure FAT32 is effected as well ).

Its actually already struck AOL they had their database with some timeout of a billion seconds which well was a long time and it overflowed and everything was timing out.

 

I wonder what software we use today that will be be running in 2038?

 

Can't they just read the negative values as continuing on after 2038, for another 68 years of use of the system? I mean, is this sort of dating ever used for dates prior to 1970?

Edit: I guess not. Time differences wouldn't work properly. Looks like the only reasonable solution is to use 64-bit integers. But that should be a really easy change in C software: it's just an update of the core libraries.

 

i assume the progs would automatically assume any negative vals as being before 1970
anyways the whole things a con, i remember y2k bug, i was pissed off so much beforehand about the insessant warnings etc, where i was saying nothing is gonna happen.
1jan 2000 happened + guess what? nothing happened, but i wasnt smug about this, i was very pissed off, basically cause noone really took the ppl to task that frauded/conned companies/governments out of billions of dollars
its almost as if they were so embarrassed that the fell for the con, they swept it under the carpet (like a nigerian email scam, if u fell for it, a lot of ppl would let it slide)
i remeber back then get offered quite good money to y2k proof some cobal programs (im train in cobol) but didnt take it up on principle cause i knew the whole thing to be bullshit.
ppl should of spent jail time

 

... and a recompilation of every single piece of software which ever did a

#include <time.h>

 

Well, I think the improtant thing would be to update time.h now so that it no longer uses 32-bit integers for the value. Then only rather old code would need to be updated.

 

It doesn't really matter how old the code is, only when it was last compiled and what the underlying defintion of time_t was at that time (presuming that the code hasn't been naughty, and has actually used time_t rather than 'int' of course).

Which version would you use to compile your dynamic libraries, and what would happen when a piece of code compiled with the other version of time.h happens to call time() ???

What you're talking about is in effect a change in the API of a very widely used core library. The impact of this should not be underestimated.

 

Well, the problem has to be tackled at some point, and better sooner than later. There's got to be a halfway decent way of doing it. I'm a bit tired now, though, and can't think straight.

 

While the IT companies saw the Y2K bug as a tremendous opportunity, it backfired in a big way: it made companies realize how much money they threw away at "random office automation". So they got punished allright.

 

i feel by 2038 there would be nuclear war between most countries in the world... it seems inevitable to me, looking at how countries are starting nuclear development...

 

I have hope that we're mostly more sane than that.

 

The time_t problem might not be a problem by the time we get to 2038. 32 bit might not be around anymore. Only really 'ancient' stuff would still have a 32 bit time_t. Sure if you want to run some old 32 bit program you might have to run it in a VM that has a date set previous to 2038, but by the time, all the software is most likely going to be 64 bit (yes I know, I'm being optimistic thinking that the 64 bit transition will be finished in the next 30 years).