Slashdot Mirror
Time's Up: 2^30 Seconds Since 1970
An anonymous reader writes: "In Software glitch brings Y2K deja vu, CNET points out a small wave of Y2K-like bugs may soon hit, though it gets the explanation wrong. It will soon be about 2^30 (1 billion, not 2 billion) seconds since 1970 (do the arithmetic). Systems that use only 29 bits of a word for unsigned/positive integers, or store time as seconds since 1970 in this format, may roll back to 1970. (Many systems that do not need full 32 bit integers may reserve some bits for other uses, such as boolean flags, or for type information to distinguish integers from booleans and pointers.)"
This is the biggest computer-related time event since Y2K, which begun on January 1, 19100!
And which systems are those?
Any of the common architectures use 29 bits instead of 31?
--
Use Vobbo for Video Blogs
SOCIETY AS WE KNOW IT WILL COLLAPSE!!!! I have to get bottled water and batteries ready! This will be a complete disaster--just like Y2K!
Oops!
My two-bit computer ran out of time the moment it was turned on...
From excellent karma to terible karma with a single +5 funny post...
With some of the fashion's today (bell bottems, et al.)
this has been a problem since 1970. is it news that c-net realizes it?
I could of course be wrong but I'm pretty sure there aren't 31-bit architectures. At least, these architectures are exceedingly rare if they do indeed exist.
What I believe this article is referring to is that some software may have been coded to use a bit in integers to store extra info. This seems like a pretty bad idea though as it would have all sorts of interesting effects on overflow and such. It would seem like it would only be useful to a very very very tiny portion of software since the overhead in using this method as a general purpose solution would be terribly difficult.
Sounds like it's just the story of yet another software bug...
int func(int a);
func((b += 3, b));
If 1K = 1024 then Y2K is 2048. We still have a ways to go on that one! :)
...is 2.6 affected by the bug??
The IT section color scheme sucks.
Okay, I read TFA. Wrong.
The article specifically states that Unices use unsigned 32-bit values to store the number of seconds since 1970. Unfortunately, it's wrong even in that respect, since most Unices have been using larger timevals for some time now.
It's fun to bash SCO and all, but come on.
perl -e 'print "seconds left: ", ((2**30) - time), "\n"'
Sex - Find It
I was born just before 1970.
I'm a billion seconds old.
Holy shit.
How many of you programmers are storing your years using 4 digits? Yeah, that's what I thought, all of you. What happens when it's January 1, 10000? Hmmm? Yes, that's right, your software will fail. It will roll back to 0, which wasn't even a year!
Now, I know what you're thinking. "There's no way someone will be using software I'm writing 8000 years from now." Yeah, and that's what programmers said 30 years ago about the year 2000. Be smart, and play it safe. Use a 5, or better yet, 10 digit year. What's a few bytes?
IIRC, bugger all went wrong. No nuclear weapons randomly fired off in any direction, no computers melted (well, none of mine)
There was no reply, though. His computer probably thought my letter was from a century ago.
Okay -- I did the math, and 2^29 seconds since January 1st 1970 would have been up on January 4th, 1987.
2^30 seconds since the epoch puts us into January 9th, 2004.
Yaz.
So if your still using UnixWare, you may be in trouble.
So that means Linux is affected also, since its mostly copied from Unixware, right?
Its epoch is midnight 01-Jan-1904 and it uses an unsigned 32-bit integer to count seconds since then. That means it will run out at 06:28:15 09-Feb-2040.
:P
But, I'm sure Apple will have released a new Newton by then!
(I don't suppose anyone's ported the Rosetta writing recognition system to other PDA's, just in case?)
I plenty left over from Y2K. For those who did not prepare for Y2K and laughed at all the suckers who stockpiled and hid in bunkers, Ha! I will finally have the last laugh! - going into my bunker now....
From excellent karma to terible karma with a single +5 funny post...
Could you be any MORE confusing? 2^30 is not 1 billion. It's 1,073,741,824. And the date as of right now is:
$ date +%s
1072051722
So, yes, there is an issue with the date overflowing a 30 bit space. I'd hardly say it's relevant, any software that made such a braindead choice (why 30 and not 32 bits?) deserves to break. But it has nothing to do with a billion or anything else related to base 10. It hit 1 billion a long time ago, and it was covered then.
2^30 = 1073741824s ~= 34y 9d 97m
1970JAN01 0000hr + (34y 9d 97m) ~= 2004JAN10 0137hr
January 10th should be an interesting day for somebody.
[You have a stable society when some nut guns down a schoolyard and the law doesn't change.]
I've seen some comments about hey, another Y2K waste of time... blah blah blah. But think of it this way:
1 - What if all the money that was spent to "fix" the Y2K bug actually fixed the bug.
2 - Most people say that all the money spent "fixing" the Y2K bug was a waste because nothing happened.
3 - How many people have insurance of some sort, and have never needed it (I am). Yet every year, you renew your policies.
There are two things we can do about these "time" bombs. The first is to do nothing and hope that all is well. Or we could audit the code that may fail. A bit like paying insurance.
[ PS: it is SCO's code, so they should pay ]
it is only after a long journey that you know the strength of the horse.
Actually, it's wrong in that POSIX states this value is signed, which is what causes it to be a problem we have to worry about before the next century. (If time_t was unsigned, various functions, such as time(2) could not return an error code. Similar deal happened with other types, such as size_t, which lead to the 2GB file problem for awhile.)
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Thanks for you're advice, which I will follow from now on.
Seriously, could we please get started fixing this 2038 bug now? I don't know if it's practical to change time_t to "long long"; if not, could we at least officially define the successor to time_t?
I know that the emergence of 64-bit chips will alleviate this somewhat, but it wouldn't surprise me if at least embedded systems are still running 32-bits in 2038.
I know that "long long" is common, but it's not part of the official C++ standard yet. Shouldn't we be putting this in the standard now? It's not too much to require language libraries to have 64-bit integer support (if necessary). This doesn't have to be painful.
I'll feel a lot better the day that I know what I'm officially supposed to use instead of time_t -- or if I can be given a guarantee that time_t will be upgraded to 64 bits within the next few years.
Can you roll over?
Infuriate left and right
http://maul.deepsky.com/%7Emerovech/2038.html
antitux@TuX0r:~$ perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
Fri Dec 13 20:45:52 1901
antitux@TuX0r:~$
hrm..
Looks like we're fucked too.
[daleg@lithium]~>perl 2038.pl
Tue Jan 19 03:14:01 2038
Tue Jan 19 03:14:02 2038
Tue Jan 19 03:14:03 2038
Tue Jan 19 03:14:04 2038
Tue Jan 19 03:14:05 2038
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
[daleg@lithium]~>uname -rs
SunOS 5.8
Interesting, it stays at the limit rather than rolling over.
These might be a problem for many slashdot readers down the road, I for one plan on being likely dead, what with being old fart already. So here's those "overflow" dates, mm/dd/yyyy U.S.A. format:
02/06/2036 - systems which use unsigned 32-bit seconds since 01/01/1900
01/01/2037 - NTP time rolls over
01/19/2038 - Unix 32 bit time, signed 32 bit seconds (that's to say, 2^31) since 01/01/1970
02/06/2040 - Older Macintosh
09/17/2042 - IBM 370 family mainframe time ends, 2^32 "update intervals, a kind of 'long second'" since 01/01/1900
01/01/2044 - MS DOS clock overflows, 2^6 years since 01/01/1980
01/01/2046 - Amiga time overflows
01/01/2100 - many PC BIOS become useless
11/28/4338 - ANSI 85 COBOL date overflow, 10^6 days since epoch of 01/01/1601
and my personal favorite,
07/31/31086 - DEC VMS time overflows
maybe a midlife crisis is just our internal clocks rolling over.
2038 will be a big mess.
For the first programming job I had (at an insurance agency) they were using 9/9/99 as infinity. So, if your benefits mysteriously stopped a few years ago...hey, it wasn't my fault!
The most interesting time related bug I came across was with a RDBMS called Advanced Revelation. The program counted days from 1/1/1970. In May 1997 the sequence counter went from 4 to 5 digits. It was interesting, the database was stable, but there were quite a few reports and add ons that were designed to expect a 4 digit number.
BTW, I built a 3/3/3333 into a program that I wrote for a company.
Yes, you are the first person ever to understand this.
Try explaining to a manager, in 1978, why he should spend twice as much on a system so that it wouldn't fail sixty years hence.
If we use Plank-Time and 256bit integers, we can handle 1.981384141637854Year*E+26. We should handle time as 256bit integer based on placktime and convert to local human time-standards as needed. We should support for a second 256bit imaginary integer and conversion to two floating point-math-units (one real and one imaginary) because some calculations in Physics involving time occur on the complex plain. I propose that zero-time be zero Julian Date.
Impeach Bush
You expect to have twenty generations of descendents by 2034? Ooh ooh I got it! You're from Alabama, right?
mogorific carpentry experiments
If you want to know what the real values are, this article and the one on cnet is wrong in so many ways... ugh, but here are the real ones that will really affect people:
:)
FreeBSD 2.2.7 will start having this clock problem on January 18th, 2038 at 20:14 (8:14PM) EST when the unix clock on FreeBSD will read: 2147483640,
20:15 (8:15PM) EST will cause FreeBSDs clock timer to claim an invalid date... joy !
That's not 2^30 folks, that's 2^31 (2147483648) or about 8 seconds after the time I quoted above.
I know because we still have one box running 2.2.7 here (and what a fun box it is too!) can't handle more than 128megs of ram. What is this - the dark ages? that was rhetorical...
I shorted A31 to ground with a screwdriver on my Motorola MC68060 board. It blew a pullup resistor on an open collector output driver. Now A31 is always low -- and I'm too lazy to replace the tiny little 100 ohm surface mount. It runs just fine as long as I don't address high memory.
I just want to know: Does that count?
Im just more worried about the 0.0481298833079654997463216641 seconds after 2004...
Not to nitpick, but that would be 0.0481298833079654997463216641 years. And besides, your calculation is a little off because you appear to have used 365 days per year :).
How 'bout this:
2^30seconds / 60seconds/minute / 60minutes/hour / 24hours/day / 365.242199days/year = 34.025551925361years
34.025551925361years + 1970 = 2004.0255519254
0.0255519254years * 365.242199days/year = 9.3326414074074days
0.3326414074074days * 24hours/day = 7.9833937777782hours
0.9833937777782hours * 60minutes/hour = 59.003626666694
0.003626666694minutes * 60seconds/minute = 0.21760000161308seconds
OR, on January 9, 2004 at 07:59:00.21760000161308, the world will come to an end.
Approximately.
Actually UNIX is really using an effective 31 bits because of the fact that it defaults to a signed quantity, and hence the highest order bit is really a sign bit. So when the clock finally increments 0x7FFFFFFF (19 January 2038 03:14:07) to 0x80000000 the time will wrap back to 2,147,483,648 seconds before 1970, e.g. instead of being Tuesday 19 January 2038 03:14:08, it suddenly becomes Friday the Thirteenth (specifically Friday 13 December 1901 20:45:52).
Those systems that are using an unsigned 32 bit time value can go on until Sunday 7 February 2106 06:28:15.
If we were to switch to 64 bits, we could use a resolution of nanoseconds with all that extra space and still represent time until Friday 11 April 2262 23:47:16.854775807 before the sign bit becomes an issue (and negative values can represent time back to Tuesday 21 September 1677 00:12:43.145224192).
now we need to go OSS in diesel cars
In standard /. fashion, I will overlook factual inaccuracies in the interest of pursuing my goal of correcting everyone's grammar. As such, I must tell you that Y2K *began* on January 1, 19100.
-Looking for a job as a materials chemist or multivariat
Firstly, every so often a leap second is added to UTC. For this reason, over timescales of years it is impossible to exactly map unix time_t and calendar times.
Another issue is determining when a transaction happened that occurred across multiple time zones...
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
> I think it'd be much nicer if the language could handle Perl-style returning of arrays.
/* waif, indeed! */ /* no jogging allowed */ /* guiness record */ /* doorway limitation */
/* name of girl */ /* diameter of waist */ /* diameter of chest at most interesting offset */ /* measure are the hips, don't get distracted, you naughty tailor */ /* it's good to hold on to! */ /* if they can't see it, they can't suck it */
The guy who posted above you 8 minutes earlier already understood the solution: return a damned pointer!
Why, oh why, is this so hard to understand? Here, I will provide a contrived, stupid example.
#define MIN_CHEST 25
#define MAX_CHEST 55
#define MIN_WAIST 19
#define MAX_WAIST 65
typedef enum { brown, blue, red, blonde, blue, cmax } colour_t;
typedef struct
{
char *name;
size_t waist;
size_t chest;
size_t hips;
colour_t hair;
colour_t eyes;
} girl_t;
typedef struct
{
size_t count;
girl_t *girls;
} girl_array_t;
void mempanic()
{
write(STDOUT_FILENO, "oh oh\n", 6);
_exit(1);
}
girl_t *createAllGirls()
{
girl_array_t *girlArr = calloc(sizeof(*girlArr), 1);
char name[64];
size_t waist, chest, hips;
colour_t hair, eyes;
if (!girlArr)
mempanic();
for (waist = MIN_WAIST; waist girls = realloc(girlArr->girls, sizeof(*(girlArr->girls)) * (girlArr->count + 1));
if (!girlArr->girls)
mempanic();
sprintf(name, "chick #%i", girlArr->count + 1);
girlArr->girls[girlArr->count].waist = waist;
girlArr->girls[girlArr->count].chest = chest;
girlArr->girls[girlArr->count].hips = hips;
girlArr->girls[girlArr->count].eyes = eyes;
girlArr->girls[girlArr->count].hair = hair;
girlArray->count++
}
return girlArray;
}
There. Everything you need. A single return value, a dynamic sized array of structs. And girls.
Of course, I didn't test it. But if you really need girls that bad, let me know and I'll make sure it builds.
Now, this is just some text to avoid the lameness filter. Doo dah. Tobacco use during pregnancy increases the risk of preterm birth. abies born preterm are at an increased risk of infant death, illness and disability. Health Canada.
L'usage du tabac pendant la grossesse accroit le risque d'un accouchement premature. Les bebes prematures font face a des risques plus grands de mort infantile, de maladies et d'incapacites. Sante Canada.
Okay. Maybe I'll de-indent my code. Stupid piece of shit.Meta-control-Q should fix that.. Oh great! Now I need more characters per line. Comments, here I come...
Do daemons dream of electric sleep()?
I love you. Seriously, and not the "I won't get it in your eye" type of love, this is the real thing.
The Y2K preparedness team at my company went crazy over the hype. They set up a big "Y2K Command Center" (commandeered a big teleconferencing room) with PCs full of nothing but Excel spreadsheets with all the functionality metrics for our whole enterprise painstakingly listed. Every ten minutes, all of us in the trenches were supposed to telephone this "command center" so they could update their spreadsheets (yes, web site "foobar" is still responding, yes, this database still works.)
About 30 minutes before Y2K hit our time zone, I noticed the maintenance guys firing up the big diesel backup generators in our rear parking lot. I asked my boss about it. "Oh yeah," he said, "They're going to take us off the power grid just in case." No big deal to us: we have UPS's on all our PCs, and the power fails over all the time in the always-spectacular Kentucky summer thunderstorm season. (Half of the building's lighting turns off to conserve power, everyone slightly gasps, but keeps working...we're used to it.)
But not so for the "Y2K Command Center." The "suits" had plugged all their spreadsheet-running PCs straight into the wall, and when we changed over to the generators (on their command) the momentary power drop caused *every single one* of their machines to go down....
We laughed in their faces openly. If that's not being hoist by one's own petard I don't know what is. It almost made it worth it not to be kissing my sweetie on New Year's Eve.
Maybe this is what the Orange Alert is about.....
This SMTP server stores the time to next retry sending a message but only the last 9 digits. So come mid 2001 Webshield would no longer retry sending a mail if the first attempt didn't work. Because it concluded it had been about 30 years since it last tried and it should give up about now.
There is a hot fix available, but this insidious problem only manifests itself if there is a problem at the receiving end so few people know they should upgrade and blame the recipient for mail that bounces immediately. Network Associates still provide software unpatched - hot fixes are only to be applied if you report he specific problem to be fixed.
If you use tempfailing (greylisting) as I do, then this immediately stuffs up any Webshield user trying to communciate with you because they will not retry after being given a temporary failure SMTP error code.
So if this example is anything to go by, then yeah, there'll be recent, modern commercial software that will fail (perhaps in non-obvious ways), with no fix available until after the event.
Recycle PCs and build a wireless community network www.hillsborough.org.nz