Time's Up: 2^30 Seconds Since 1970 675
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.)"
Yay! (Score:5, Funny)
You, sir, are incorrect (Score:5, Funny)
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.
Some systems... (Score:4, Interesting)
Any of the common architectures use 29 bits instead of 31?
Re:Some systems... (Score:5, Informative)
So maybe a Lisp Machine might have this problem? Of course, Lispers will tell you that they'd always have the sense to use a bignum
Re:Some systems... (Score:5, Insightful)
Re:Some systems... (Score:5, Informative)
Re:Some systems... (Score:5, Interesting)
So maybe a Lisp Machine might have this problem? Of course, Lispers will tell you that they'd always have the sense to use a bignum :)
The Symbolics Lispms had wider words than PCs today. They used 36-bit words on the 3600s, with 4 bits of tag and 32 bits of data for numbers (or 8 bits of tag and 28 bits of data for pointers). They used 40-bit words on the Ivory, with 8 bits of tag and 32 bits of data for all types. So either way, the number is a 32-bit value. (This is why Lispms traditionally spec RAM in megawords, not megabytes.)
That aside, like I mentioned in my other post, they said that all the date code is bignum-friendly anyway.
Re:Umm, none? (Score:4, Interesting)
In fact, I work on a processor in which one engine has 20 bit words, another has 18 bit words, and another does multiplies out to 29 bits (15 bit x 14 bit).
Tim
Re:Some systems... (Score:5, Funny)
Um, not to be quarrelsome or anything, but I'm not sure sure you'll find anyone here willing to make that distinction.
Present company execpted, of course. :)
Re:Some systems... (Score:4, Funny)
It was flame bait and I just wanted to post an educated rebuttal.
Translation:
OH NO! (Score:5, Funny)
Re:OH NO! (Score:5, Funny)
Re:OH NO! (Score:5, Funny)
Re:OH NO! (Score:5, Funny)
Re:OH NO! (Score:5, Funny)
Ok, you asked for it
The only two tools a handyman will ever need are duct tape and WD40. If it moves but it shouldn't, use the duct tape; if it doesn't move but it should, use the WD40.
I am not worried! (Score:5, Funny)
Party Like Its 2037 (Score:5, Interesting)
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.
Re:Party Like Its 2037 (Score:5, Funny)
That does NOT count as a sufficient documentation of the above feature!
Re:Party Like Its 2037 (Score:4, Funny)
Back in 1999, some BBS door functions stopped working, apparently due to running out of single-digit dates. *sigh*
In the Closet I have a P90 that ever since Y2K, firmly believes the year is 2094. Oddly enough, NWDOS7 thinks this is a perfectly acceptable date!
Re:OH NO! (Score:5, Funny)
Calm down, man! Look, society might collapse or it might not - either way, that's no reason to down some kind of odd suicide cocktail.
so in other words.. (Score:3, Funny)
Re:so in other words.. (Score:5, Interesting)
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.
Re:so in other words.. (Score:4, Funny)
Re:Not quite accurate (Score:4, Interesting)
Taking into account leap seconds:
env TZ=/usr/share/zoneinfo/right/GMT date -r 1073741823
Sat Jan 10 13:36:41 GMT 2004
Ignoring leap seconds:
env TZ=/usr/share/zoneinfo/posix/GMT date -r 1073741823
Sat Jan 10 13:37:03 GMT 2004
(BSD date's -r option is useful sometimes)
Yeah well... (Score:4, Funny)
Re:Yeah well... (Score:5, Funny)
I thought we already rolled back to 1970's (Score:5, Funny)
yawn (Score:5, Funny)
RTFA (Score:3, Informative)
Re:RTFA (Score:5, Informative)
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.
Re:RTFA (Score:5, Informative)
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.)
Duh, it can! (Score:5, Funny)
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...
Re:RTFA (Score:3, Informative)
Re:RTFA (Score:5, Funny)
So that means Linux is affected also, since its mostly copied from Unixware, right?
Re:RTFA (Score:4, Funny)
Re:RTFA (Score:4, Funny)
It's a long-standing rule of Fight-O-Net / UselessNet / Slice'n'DiceDot that when one attempts to correct the grammer or speling of another, invariably they themselves will make a misteak.
If for no other reason, of course, than the fact it doubles the fun of language police.
Re:RTFA (Score:4, Funny)
I don't think there are 31-bit architectures (Score:5, Insightful)
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...
31 bit architecture is very common (Score:3, Informative)
Re:I don't think there are 31-bit architectures (Score:5, Interesting)
Using a couple of bits in an integer for data type is usually (in my experience) called 'tagged data.' I use it in Smalltalk VMs as an optimization -- the "objects" representing Integers are really just 31-bit integers with an extra zero-bit stuck on the LSB. (Object pointers have an LSB of 1, so you mask that to zero before using them and keep everything 16-bit aligned.)
Essentially what you wind up with there is a tradeoff: you can perform simple arithmetic and logic on the Integer "references" without actually having to allocate an object to hold an Integer, but you lose a bit of dynamic range. In my experience, it's an acceptable tradeoff, and it lets you have all the advantages of a true OO system without the performance penalty of having to use an object for, say, every loop variable.
So there's an example of why you do that. The aforementioned Smalltalk systems wouldn't be vulnerable to this date issue, however, as their integers will automatically convert themselves to arbitrary-precision numeric types as needed.
Re:I don't think there are 31-bit architectures (Score:4, Interesting)
One of the fun tricks you can do is use the bottom 2 bits for tagged data type, and then reserve two of those for immediate integers: one for even ints, and one for odd. That way, you get 3 tag types, with 30 bits of pointer, but you still get 31 bit integers instead instead of 30 bit. So the tags might look like:
01: even int
10: pointer to object header
11: pointer to array/string header
Then you convert raw data to an int with >>1, and to a pointer with &~3 (you only need 30 bits of pointer if all objects are word-aligned in a 32 bit address space.)
Lucid Common Lisp used this kind of system, and Lucid Emacs/XEmacs do something similar.
I have one! (Score:5, Funny)
I just want to know: Does that count?
Re:I don't think there are 31-bit architectures (Score:5, Informative)
Are you sure about that? (Score:4, Informative)
typedef __kernel_time_t time_t;
http://lxr.linux.no/source/include/asm-i386/posix_ types.h?v=2.0.39 [linux.no], line 21:
typedef long __kernel_time_t;
It's defined as a long for the other architectures as well. AFAIK a long is 32 bits on all platforms Linux 2.0.39 runs on.
Re:I don't think there are 31-bit architectures (Score:5, Informative)
Re:I don't think there are 31-bit architectures (Score:5, Informative)
Of course you're wrong
The IBM OS/390 and Z/OS operating systems, which run on most IBM mainframes, are both 31-bit.
Re:I don't think there are 31-bit architectures (Score:4, Informative)
They're actually 32-bit platforms but only are addressable by 31 bits. I believe they do arthimetic on 32 bits...
But Y2K hasn't even come yet... (Score:5, Funny)
I fear to look... (Score:4, Funny)
How many seconds you have left: (Score:5, Informative)
Re:How many seconds you have left: (Score:5, Informative)
$ echo seconds left: $(((1 << 30) - `date +%s`))
(assuming your date(1) supports the %s extension)
Re:How many seconds you have left: (Score:4, Funny)
perl -we 'print "seconds left: ", ((2**30) - localtime), "\n"'
Argument "Mon Dec 22 01:44:41 2003" isn't numeric in subtraction (-) at -e line 1.
seconds left: 1073741824
Not too Informative, if you ask me...
OMG (Score:5, Funny)
I'm a billion seconds old.
Holy shit.
Are you a dog? (Score:5, Funny)
mid life bug (Score:5, Funny)
Re:OMG (Score:5, Funny)
I was born just before 1970. I'm a billion seconds old.
Worse yet, you're in your 30s. Sorry, dude.
Re:OMG (Score:4, Funny)
Prepare for the Y10K Bug! (Score:5, Funny)
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?
Re:Prepare for the Y10K Bug! (Score:5, Insightful)
Embedded systems (Score:4, Insightful)
Perhaps all time counters should be bignums?
Bad idea. A "system to contain radioactive wastes" will usually be an embedded system with a fixed memory. Fixed-memory machines need fixed-size data structures, and a 64-bit count of seconds should hold even over lifetime-of-the-Universe or lifetime-of-copyright time scales.
Re:Prepare for the Y10K Bug! (Score:5, Funny)
deja vu? (Score:5, Funny)
Y2K (Score:5, Funny)
There was no reply, though. His computer probably thought my letter was from a century ago.
No sympathy for these guys (Score:4, Informative)
Did the math. (Score:5, Informative)
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.
Re:Did the math. (Score:5, Interesting)
Phew, my Newton's Safe! (Score:5, Funny)
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?)
Wrong writeup. (Score:5, Interesting)
$ 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. [slashdot.org]
When becometh Friday the Thirteenth (Score:5, Informative)
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).
does anybody else think... (Score:4, Interesting)
header containing:
2-bits (E) for # of bits for Epoch
1-bit for whether the time is a floating point format
if not floating, then:
2-bits (N) for # of bits for the time
2-bits (n) for # of bits for the resolution (1/2^n) (e.g. n=8 would mean 1/256 second resolution)
if floating, then follow some IEEE standard representation.
Re:does anybody else think... (Score:3)
Re:does anybody else think... (Score:4, Insightful)
Gee that's small potatoes (Score:4, Interesting)
You think I'm trying to be funny ? well let's see : people were worried that systems built in the 80s and before would display the 99 Cobol date bug, and/or the 2-digit date bug in 2000. 1980 and before is 20+ years ago, and there weren't that many computers/microcontroller around during those 20 years compared to what's to come, and operating systems weren't very unified. Today in 2004, we have kajillions of Unix machines around : how much do you bet a lot of these will still be running 30 years from now ?
This said, I'm not bracing quite yet to tell the truth
ObCalculation (Score:5, Interesting)
1970JAN01 0000hr + (34y 9d 97m) ~= 2004JAN10 0137hr
January 10th should be an interesting day for somebody.
Re:ObCalculation (Score:3, Insightful)
Sat Jan 10 13:37:04 CST 2004
Re:ObCalculation (Score:5, Informative)
date -u -d "1/1/70 `dc -e '2 30 ^p'` secs"
Sat Jan 10 13:37:04 UTC 2004
See man date
A note about the "funnies" (Score:5, Interesting)
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 ]
Re:A note about the "funnies" (Score:5, Informative)
There were, in fact, many problems that were found and fixed before they did any harm.
A lot of infrastructure was upgraded on somewhat dubious claims of Y2K problems. In some cases, resetting the system clock once on 1/1/00 would have sufficed.
Consulting firms and contractors had a feeding frenzy. Some added value, others did not.
Many corporations were frightened by the prospect of lawsuits that might occur if they had Y2K problems. Lawfirms were licking their chops with anticipation.
As a result of all of the above, for the only time in recorded history CIOs could get whatever they wanted. Naturally, they played it safe. Wouldn't you?
Re:A note about the "funnies" (Score:4, Insightful)
Seriously, why can't we fix this damn thing now? (Score:5, Insightful)
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.
Re:Seriously, why can't we fix this damn thing now (Score:4, Funny)
Yes, we could fix the bug now. Likewise, we could also address world hunger, the deficit, the exploding crime problem, terrorism and a host of other issues with such cautious, preventative measures, but doing so wouldn't give us the instant gratification we desire now, so we'll let your children deal with the deficit, crime, terrorism, poverty, hunger and the time bug. We have better things to do. I'd write more, but I think "Friends" is coming on.
20 generations by 2034? (Score:5, Funny)
For Example (Score:3, Funny)
yup... (Score:5, Informative)
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.
different response on solaris 8 (Score:5, Interesting)
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.
Oh no! Groundhog day! (Score:4, Funny)
rash of naughty dates coming (Score:5, Informative)
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
Re:rash of naughty dates coming (Score:5, Informative)
I'd like to add to that January 1st, 2032, which is when the date structure in older Macs and PalmOS devices will overflow.
Yaz.
Re:rash of naughty dates coming (Score:5, Funny)
Use Planck-Time and 256Bit Integers (Score:5, Interesting)
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.
Re:Use Planck-Time and 256Bit Integers (Score:4, Interesting)
This is a response to the first two replies
John Hasler:
Zero-time should be the instant of the Big Bang. By the time 256 bit cpus are standard we should know that accurately.
I thought about zero-time being the big bang. I figured that since the big is not known very accurately, it would not be a good idea. On second thought, if we revise the time and the conversion-tables (something which is necessary anyway as the value of the Planck-Time-Unit (5.4*E-44)) with revision of the time of the big bang, it will work. If we use the time of the big bang, we will have to include the version of the revision along with the time stamp or else the text file from one year ago will show as from one billion years ago while the spreadsheet from 2000 AD, will not exist for two billion years.
Anonymous Coward:
(BTW, too bad I don't have some mod points to spend -- Planck units are the perfect rebuttal to those that claim the metric system is the best around)
Natural units (Planck-Units) are best. After them, Metric Units are second best. One must remember that the metric system predates the discovery of Planck-Constants. The metric system has definite advantages over other previous systems:
Natural units are too small for practical everyday use. Metric units are in the convenient range for everyday use. Still, it is important to remember that metric units are arbitrary.
Among my favorite arbitrary units is the byte, system for measuring memory:
2^10
This way, the amount of memory a computer can handle is always a round number (because the algorithms used for memory allocation, use binary mathematics). As an example, my filesystem can support files of upto 16 exobytes in size.
Actual figures here (in case you wanted to know) (Score:5, Informative)
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...
Salvation For Loveless Geeks? (Score:4, Funny)
Sally Roberts, pucker up.
Time is complex... (Score:5, Informative)
Firstly, every so often a leap second [wikipedia.org] 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...
My Y2K Story (A little offtopic) (Score:4, Funny)
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.
Orange Alert (Score:5, Funny)
Already commercial failures on 1 billion seconds (Score:5, Informative)
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 [slashdot.org] (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.
Re:subject (Score:3, Informative)
Its interesting, how no one considered this would happen eventually and just started to use 64 bit ints to store this from the long run.
Someday, we will hit a very high year, and these sort of problems will hit us as well
Re:subject (Score:3, Interesting)
Re:subject (Score:4, Interesting)
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.