Slashdot Mirror
You've Got 25 Years Until UNIX Time Overflows
CowboyRobot writes "In 25 years, an odd thing will happen to some of the no doubt very large number of computing devices in our world: an old, well-known and well-understood bug will cause their calculation of time to fail. The problem springs from the use of a 32-bit signed integer to store a time value, as a number of seconds since 00:00:00 UTC on Thursday, 1 January 1970, a practice begun in early UNIX systems with the standard C library data structure time_t. On January 19, 2038, at 03:14:08 UTC that integer will overflow. It's not difficult to come up with cases where the problem could be real today. Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage. Or imagine those phony programs politicians use to project government expenditures, or demographic software, and so on. It's too early for panic, but those of us in the early parts of their careers will be the ones who have to deal with the problem."
those phony programs politicians use to project government expenditures
The programs are real, even if the math may be phony.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
NetBSD has switched to a 64-bit time_t.
Hail Eris, full of mischief...
E pluribus sanguinem
The IOS reminder service will fail for the first week in January atleast once before then :)
Build a Man a Fire, and He'll Be Warm for a Day. Set a Man on Fire, and He'll Be Warm for the Rest of His Life.
Current Unix systems have 64-bit (where not 128-bit) timestamps!
Maybe some databases could store timestamps as 32-bit unsigned long with basline at 1970-01-01...
But you know, Human Intelligence has limits, his stupidity has none!
Standing before the steam roller....
"Stoooooooooooooooooooooooooooooooooooooooooooop".... .... "Stooooooooooooooooooooooooooooooooop"....
I understand, we need time to correct the issue, but...c'mon?!
Slow news day?
"Helping to keep you two steps ahead of the Thought Police!"
32bit unsigned, not signed! What'd be the negative timestamps for? Ages before 1970?
Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
As far as I am aware, only old Unix computers still use 32-bit time_t vars...
I put in my time working on the Y2K fix. I'll be retired in 5 years, so let the kids of today fix this one. Hell, they need jobs.
Was this a USENET post from '94? Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages. We did not hear an earth-shattering kaboom.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Having a 64-bit will not solve this at all. The problem lie in the software, if a 32-bit time structure as been used, no matter on what computer it's running it will be emulated as a 32-bit application with only 32-bit of memory for time allocation. It will bust, I can see a whole bunch of old program still running because "it work" and company, especially big companies, do not re-write the software in 64 bit.
This could be worse than Y2K!
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
Dice (r) is the best place to find programmers to fix your Y2k38 problems.
Do you even lift?
These aren't the 'roids you're looking for.
64bit time will solve it for anything that uses time from the system directly. Meaning all those perl and bash scripts that run so much stuff no one thinks about, from billing to transferring data between companies to scheduling your next vacation are going to be fine.
What will not be fine is crusty old compiled code that was 32bit. Hopefully they are just a recompile away from being fixed. Sadly that is likely not to be the case as generally corporations do not have that kind of foresight.
My uptime!
After all, we handily averted Y2K with decades to spare, and the internet has been migrated to IPv6 for the past ten years. :-P
The Wikipedia article is much better than the Byte article. (Do people still read Byte? I don't remember seeing it since the 80's.)
One thing that seems a little different from Y2K is that this bug seems to be prevalent in a lot of embedded systems. To me that seems harder to test than a desktop system. On a desktop system, you can just set the time to Dec. 31, 2037, let it roll over, and test as much stuff as possible to see if it broke. You can't do that with a car or an airliner.
Find free books.
>> those phony programs politicians use to project government expenditures
That's Excel in most cases, I bet. As long as spreadsheets can handle up to 50 rows and numbers up to 3000 I suspect all will be as it is today.
Time overflowing sounds like a good plot, instead of the usual time repeating, or other cliche time related plots. I'm just curious what the effects of a time overflow would be. *ponders* Maybe a break down in causality?
So it will be someone else's problem.
that give time for there to be a PHD level class coving fixing this and then you will only find job's that pay like 30K a year to fix it and your loans will be like 500K
"Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage."
Well, that's a not-unreasonable example that almost certainly exists already, and seeing as we're only 25 years away - seems like the banks didn't really have any problems with that - at least, none they've advertised.
So the real question is: How big a problem is it really? Application software can trundle off and do what it likes and ignore the clocks it knows are wrong, and 64-bit time systems like are available today are carrying on quite happily.
Y2K was like this - doomsaying about how your mortgage would fail and your wages would stop. Sure, it could - theoretically - have caused problems. But only if your software managers in charge of those things were complete idiots in the first place (and using an app that was written in the 60's, unchanged, isn't an excuse and STILL makes you an idiot).
Y2.038K is definitely MORE of a problem. Definitely. But it's obviously not something that those with software that looks that far ahead are worried about at the moment. And in 25 years, in any of my current computers are still operational I will be incredibly impressed. If any of my computers NEXT YEAR aren't running 64-bit OS (whether or not they have 64-bit clocks) I will be slightly put out! So 25 years to move to 64-bit clocks? No problem.
Cowboy Robot is yet another example of someone trying to use "facts" to create alarm, raise money, and achieve world government. If there were really a time problem in UNIX, and I don't believe it for a moment, it's not necessarily caused by human activity. I prefer sunspots. Yeah. Sunspots.
I'll be almost 2.5 gigaseconds old and won't give one nanoshit.
So whoever is going to fix it, I don't want my check to be late.
Now get off my future lawn.
no comment
At least none will be able to say slashdot was late with this report.
If you have a 64 bit PC and OS, it should be little more than a recompile. This is why it's important to have the source.
Give me Classic Slashdot or give me death!
Why would they use a signed integer for something that started at zero and cannot be negative?
Rebaseline the count from say 2000; if it's good enough for the Pope to do it's good enough form me. And then we'd have Old Unix and GNU Unix
I'm a consultant - I convert gibberish into cash-flow.
http://slashdot.org/comments.pl?sid=3356429&cid=42468505
But thanks for pointing it out again. Don't forget to stock up on Spam and Treet.
Or are they strings... I think the DB admins should make them integers, and when they overflow, the site should just be shutdown, or new users get wrapped to low UIDs and have shared accounts.
The G
True. Don't recompile and continue whining.
Compiling away isn't always that simple.
You'd be amazed how many people code depending on the fact that sizeof(long) == sizeof(int) == sizeof(void*) == sizeof(time_t) == 4 even when they don't need to and structures are often mapped directly onto binary data, either from disk or network.
I don't actually imagine that 2038 will be much of a problem - most of the issues that will be triggered by the above assumptions will occur between now and then and will be fixed as they occur.
Then 2038 will loom and there will be a big drive to fix everything (else), the magic time will occur and there will be little more than a whimper. Then everyone will complain about the hype about a non-existent problem.
I am quite looking forward to having the option of some lucrative consulting income in my early retirement should I decide I need it. :-)
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
There -- it's fixed.
the growth in cynicism and rebellion has not been without cause
64-bit is taking over already everywhere. In 10-15 years, you will have a hard time finding a 32-bit computer.
The embedded world will still have a lot of 32-bit (as well as 16- and 8-bit) stuff for years to come.
That's where the big problem will be: not with the systems on your desk (or on your lap, or in your pocket), but rather with the hundreds of little CPUs that you don't see (and you may, or may not, be aware of).
PHP is still screwed, no 64-bit integers.
Stop warning people! The Unix 32 bit Epoch cleanup is my retirement plan! I'll make a killing fixing legacy software when the kids out of school only know how to point and click through their GUI IDE's and don't know the difference between a short, an int, a long, and a long long... and time_t is completely foreign to them.
After having the time overflow on a previous offering, DEC made sure this wouldn't occur anytime soon in VMS. Quoting from the Wikipedia article on VMS, "The 100 nanosecond granularity implemented within OpenVMS and the 63-bit absolute time representation (the sign bit indicates absolute time when clear and relative time when set) should allow OpenVMS trouble-free time computations up to 31-JUL-31086 02:48:05.47. At this instant, all clocks and time-keeping operations in OpenVMS will suddenly fail, since the counter will overflow and start from zero again." VMS engineering assures us that a patch will be available to take care of this problem several years before the overflow occurs.
There is no God, and Dirac is his prophet.
Seems like we've run out of end of times theories to freak out about. Might as well use this one.. Let's pretend also that it happens Jan 1 2014 at exactly midnight. And that the world will come to an immediate end.
http://en.wikipedia.org/wiki/John_Titor
All we need is to understand the plans of the time machine that John Titor put on the internet.
Then, we will be able to send another John Titor back the to the 70's to get an IBM 5100 to solve the problem...
Remember how the world was going to end on Jan 1, 2000 because no one could possibly imagine how computer software could be ready for the new millennium? Except, of course, that people who write computer software had known about the issue for 15 years and had already changed most code to not be affected.
This is going to be the same thing. Long before we reach 2037, programmers are going to be changing their code to not be impacted by it (probably simply moving to using a 64-bit integer to represent time - which has nothing to do with whether the hardware is 32-bit or 64-bit - one can still perform 64-bit operations on 32-bit hardware - its all a matter of software). The moment that the kernel's start tracking and presenting time as a 64-bit seconds-since-epoch (which may require some apps to be reworked if they hard-coded assumptions about the size of a time_t) the problem goes away. I am 100% confident that Linux, Windows, OSX, etc will have all made that change long before 2037 rolls around.
Of course, the general public, and the media, will continue to play it up as if no one could possibly have planned for such an event - mostly because the general public's idea of Engineering comes from Hollywood, where Engineers design indestructible super ships which can be taken out by going into a public lavatory and flushing three toilets at the same time.
I am quite looking forward to having the option of some lucrative consulting income in my early retirement should I decide I need it. :-)
Then my goal is to thwart your retirement plan. I will contract a low-wage programmer from a yet-to-be-determined developing country to write a piece of software that corrects the issue in any source code and recompiles it for you. I'll sell licenses for $1kUSD a pop, which by 2038 will only be enough to cover the cost of a McDonalds Synthetic Cheeseburger Paste from the Value Menu.
Apparently wizard is not a legitimate career path, so I chose programmer instead.
Y2k was a boom for technology contractors such as myself. The years leading up to Y2k38 will be good too. Think of all the code that will need to be totally rewritten. I know, there is that faction of people that want to see technology undo itself, and the world end, but for those of us that live in reality... it'll be great. Honestly, I wish we had these kinds of crises more often.
This signature has Super Cow Powers
Unlike all the "big problems" in the world today, this one is real! I don't care about Kate having a baby or prince Harry smoked pot with Justin Beaver well Kim Celebrities is having an affair. This is actually a very real and important issue, yet how many people outside of the "nerd" community even know it exists. When the puck drops and Unix time overflows, I can promise you that all of a sudden what Kate's child is going to wear to her wedding is all of a sudden the least important headline in the papers.
and your loans will be like 500K
Per textbook
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I agree. Who was unaware of this? When did Slashdot become an aggregate for COMP SCI 101 courses and Learn to Program in 24 Hours books?
Apparently wizard is not a legitimate career path, so I chose programmer instead.
Imagine a mortgage amortization program projecting payments out into the future for a 30-year mortgage.
In 1988, the data processing division of NCR which provided loan processing services to small banks had still not fixed the Y2K bugs in their software. In order to make 30-year mortgages, their customers had to calculate the amortization table for a 30 year loan to figure out what the balance would be at the end of December 1999, then actually put the loan into the system as an XX year YY month loan coming due at the end of 1999 with a balloon payment of that amount. All in the hope that some time in the next 12 years NCR would fix the problem, even though the prior 18 years had not been long enough. (Well, not really. At that point all their customers were actively working on bringing their processing in-house, since the AS/400, along with a couple of upstart software companies, was making that far more practical than it had ever been.)
Yes, I am old ;-)
... for a sufficiently large value of "67 years."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I'll be too old to care
a McDonalds Synthetic Cheeseburger Paste from the Value Menu.
#tagline: "A perfect blend in every bite..."
Based on the fact that this stopped being true a long while ago, yes, if the number is actualy big, I'd be amazed.
Rethinking email
All that canned food I stored for Y2K is beginning to expire. Time to restock!
Problem solved for another 40 years. By then Civilization will be gone anyway, as all of the natural resources are depleted leaving a scorched or nuked Earth.
You think you feel silly? Imagine how the Mayans felt!
Having a 64-bit will not solve this at all. The problem lie in the software, if a 32-bit time structure as been used, no matter on what computer it's running it will be emulated as a 32-bit application with only 32-bit of memory for time allocation. It will bust, I can see a whole bunch of old program still running because "it work" and company, especially big companies, do not re-write the software in 64 bit.
Did you miss the y2k thing?
We know that big companies are willing to invest large sums of money to make sure that things doesn't break 2038 and a lot of people will be required to be at work when the expected incident is supposed to be happening just to make sure that they can react directly if things break.
Big companies will rewrite or recompile their internal software if necessary. If it's not necessary they won't but then it will also not be a big problem.
[Like]
john titor anyone?
Think of all the code that will need to be totally rewritten.
I don't think that phrase means what you think it means...
You are very unlikely to need millisecond precision when planning a year in the future. So fix one is to use a day-based counter such as Julian date.
OK so we're over that problem but dates are NOT LINEAR. When did you start your current job? "June 2006" (note no day). When did you leave? "Not yet." In many applications we need Beginning-of-time, Not known, 1986, August 1986, 17 August 1986. Then we need rules for 'February 27th plus one month'. For the answers look at http://vulpeculox.net/day/index.htm . (Keen coders welcome.)
Not a problem since we'll all be running Windows 11 by then.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
It is for experimental exercises such as UNIX.
I worked for a DoD contractor in 1999. Our customer had a piece of ground support software for the A-10 that they wanted to make Y2K compliant. Of course, we had to write up a detailed description of the problem and what it might affect so the customer could justify the expenditure to the bean counters. Then we had to write up a preliminary design review to get approval at the high level for what we were going to do. Then we had a critical design review so they could sign off on the detailed implementation of how we were supposed to implement the changes. I based my CDR on the code I had already written to fix the problem. Then I had to put together a testing specification so that we could prove that our date fix didn't destroy the functionality of completely unrelated code. Then we had to go test it on site, do a test report and a final project report.
Nine month project. I don't remember for sure, but I'm pretty sure that the government spent half a million on the entire program. I was the sole technical actor. I changed something like 20 lines of Pascal code, which took me maybe a week or two. I think I spent more time figuring out how to put together their ancient tool chain than writing actual code. Your government dollars at work.
Today's Sesame Street was brought to you by the number e.
I've got an embedded system using a commercial cross-compiler. I've tried setting the clock to around 2038 to see what happens. The date/time functions in the C library start to fail before the roll-over. (You can disable them in favor of your own, but it seems to be a pain in the ass.) I seem to recall it starts to have problems in 2036. This system controls lighting in small commercial buildings, so I hope they'll get to upgrade in 20 years or so. In any case, I felt it was safe to only use 2 digits in the clock setting screen as they'll probably be long gone by 2099.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Remind me to tag you as "evil bastard" if I ever look at your profile, alright? Not only do you destroy a future old man's retirement scheme, but you turn my stomach with a future menu item. Evil.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
Unigeddon
Table-ized A.I.
What about my raspberrypi?!
Based on the fact that this stopped being true a long while ago, yes, if the number is actualy big, I'd be amazed.
Start looking around more. Idiots abound.
One good thing to remember: Sun's (now Oracle's) C++ compiler has an "-xport64" option that will produce warnings about such idiocy. First thing I did when I had to "help" a subcontractor who had a lot of "expert coders" do their damn job was to run that compiler with that option against their code base. There were something like 3,000+ hits in few hundred thousand lines of code. So much for "expert coders".
Of course, I should have known that when I got lied to by their manager about how they followed their own code walk through practice. (Hint: any developer who doesn't want you to see their code is almost certainly a bad coder - the best coders I've ever seen ALL have no qualms about letting anyone see their work. And resistance to code walk throughs is strongest from the shittiest developers....)
2038 is so close to the singularity that the computers will most likely just fix it themselves.
"but those of us in the early parts of their careers will be the ones who have to deal with the problem."
I'm 25 and we don't use Unix here. Those two statements are not unrelated. Yay, it doesn't affect us.
If you have a 64 bit PC and OS, it should be little more than a recompile.
A number of comments have claimed this: recompile with 64-bit time_t and the problem goes away. Unfortunately, for many apps it's not quite as simple as that.
Certainly, for those apps which only deal with time information internally, and in a transient fashion, this will be sufficient to eliminate the problem.
However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol, or basically anything which sends the data structure outside the application is still going to require work on how to handle the migration.
What happens if your app is required to talk on the network? If there are few enough machines involved, then sure, you can upgrade all of them at once, but if it's a large or distributed operation, there needs to be a transition plan. How will older clients and newer clients interoperate?
If data is saved, how will the recompiled application interpret old files? Does it need a way to distinguish them? Can old data be automatically converted? Are there cases where old data may be compromised? (e.g. those 30 year mortgages probably have the wrong end-date stored...) How will we handle those cases?
What about situations where time information is used to prime other calculations - is it okay to affect those other calculations? Serial numbers, PRNGs, UUID generation, etc - the situation has to be assessed. Many cases might be fine, but you can't make a blanket statement for all cases, so each calculation must be vetted.
In the end, the result is that there is work to do. Much of it will be easy to fix, but the assessment still needs to be done.
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
You know what that phrase means, and he knows what that phrase means, but does his client know what that phrase means?
I realized with horror this bug was to occur. The professor reassured me that by that time, mankind will have advanced so much that we will have replaced all the hardware and all the software in the world where this might be a problem. He said Unix itself probably will be replaced. He didn't mean that alternatives would be available, i.e. a different OS users COULD install, or different hardware users COULD use. He meant that man would have taken the effort, such that no person could go out in the world and find hardware/software where this would be a problem (except maybe a museum). I really, really don't see that happening. Maybe critical infrastructure like nuclear plants, military, power grid, water, etc. will fix the problem at great expense to the government, but no way will the rest of the world. And it's not mom and pop stores and small public libraries that will shut down. It's going to be a big problem for a lot of things that daily affect each of us.
"We'll fix it later" should not really ever be the philosophy of any OS.
How many 32-bit program will be mission-critical in 2038? How many 8 or 16-bit programs are mission-critical today? Some I imagine, but not plenty.
I didn't think that was going to happen until 2048.
Hmm.. Mortgages is not exactly a good example. I don't really need to calculate my mortgage payments down to the second, just down to the day.
And just who are you to tell me it's too early to panic? I'll panic when I want.
In 25 years, I seriously doubt this is going to be an Issue. At the current rate of Population explosion and Debt, I doubt many people will even own a Computing device. And of course, because this is Future related and nobody knows the Future (Except John Titor) there will probably be another article in the Future, explaining why this Article was wrong.
Given a head start of 25 years, shouldn't the automated code remediation tools be quite sophisticated by then? Someone is probably already making a product or open source tool.
Future generations may think we intentionally used these values (e.g. start date and 32-bit signed integer) because we somehow know/predict the Earth will end on this date...
How did a poster who didn't read the article get "Insightful"?
Go read the article. You'll see screenshots of iOS 6.1 displaying weirdness, and a link to a Google Nexus 7 with issues too.
So no, this is not just some Windows 8 whiner. Here's the link again. Click it this time!
http://www.informationweek.com/byte/personal-tech/25-years-from-today-a-time-for-bugs/240146640
If this were Usenet, I'd killfile the lot of you.
$0.5M to be air-tight sure that a simple 20 lines of Pascal code doesn't crash one (or more) of the hundreds of A-10s in active service, each one worth $12+M, not to mention keeping those pilots safe.
Yes. Definitely our government dollars at work.
The story about the retired technician sending the company which demanding an itemized invoice, "fixing issue: $10; knowing how to fix it: $19,990" needs to be updated with an additional "Jumping through multiple levels of management CYA red tape" line item costing three times more.
Based on the fact that this stopped being true a long while ago, yes, if the number is actualy big, I'd be amazed.
If you look closely, he or she posted an expression where the result of a comparison was compared to 4. Comparisons produce a value of 0 or 1, so the result is never equal to 4, so the expression was always 0.
The banks had 30 years mortgages in 2008 (and after) and their software seems to be doing fine. I'm fairly certain banks have already taken care of this. The companies that don't need to think so far in advance may have issues, but as long as their software isn't worthless and they're running relatively recent OSes, I doubt this will be an issue.
This is simply not true.
ANY program that uses a 32 bit value to store/manipulate timestamps will be vulnerable to the bug. Any program that represents time internally as a 32 bit value, will be vulnerable to the bug.
Think of a program that reads the current timestamp into a 32bit value, then manipulates it, and outputs it. A recompile will not fix that. You'd have to change the code to make it use a 64bit value internally, plus any changes as necessary to support that.
You can see why people are extremely reluctant to tinker with man-rated systems.
Don't blame me, I voted for Baltar.
The summary says:
It's too early for panic, but those of us in the early parts of their careers will be the ones who have to deal with the problem.
I dealt with the Y2K issue in a Telco environment. When the problem is looming closer, take me out of retirement and offer to pay me a small fortune, and I may consider showing you young lings how it's done. ;-)
*** Suerte a todos y Feliz dia!
The real WTF is Pascal code for A-10 ground support.
Panic? Y2K was a time when a huge amount of investment to upgrade systems occurred. It was a surge for everyone in IT when all sorts of projects that hadn't been able to get funding were able to get funding. Oh for those older people, it gives a great chance to contract writing programs in languages or using techniques younger people don't know. Those old Assembly language, C, Paradox, FoxPro... skills will be back in vogue.
Why panic?
Which is why you should be using time_t which was increased to 64bit years ago. Always store on disk as ISO text or in 64bits and you'll have no issues. 25 years is plenty of time to fix it as long as everyone codes well.
And I just changed my compiler to make "char" be 32 bits, and then I recompiled a few libs and all my source code, and now all my programs automagically support Unicode!
Also known as The Year of Linux on Desktop...
I don't want to have to listen to the bubblegum pop autotuned remake of 1999.
I swear to God...I swear to God! That is NOT how you treat your human!
On January 19, 2038 we can all party like it's 1970!
Quit trying to fix the software, or move everything to 64-bit tools. The answer is much simpler: Just declare The Second Coming, and make, say 2020 the new Year One. Now you won't even have to worry about Y2K for another two thousand (decimal) years!
https://app.box.com/WitthoftResume Code: https://github.com/cellocgw
Going to start buying them now.
Website Just Down For Me? Find out
Well I'm planning on retiring January 18, 2038 and my mortgage should be paid off by then. Not my problem.
Don't worry about problems. That's mostly a matter of using a 64-bit time_t and perhaps a short debug session. Generally no big deal.
But some file formats have 32-bit time_t fields in them. gzip, for certain. tar probably. Fixing those is a serious cross-program synchronization nightmare.
will be finally "The year of Linux on the desktop"
However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol, or basically anything which sends the data structure outside the application is still going to require work on how to handle the migration.
What happens if your app is required to talk on the network? If there are few enough machines involved, then sure, you can upgrade all of them at once, but if it's a large or distributed operation, there needs to be a transition plan. How will older clients and newer clients interoperate?
And this is why we use JSON (or for the well-intentioned but overly-verbose of us, XML). Want to store a number of arbitrary size, like maybe a timestamp, in JSON or XML? Just print() it into the stream or file. If you and your fellow developers are already doing this, congratulations, your files will automatically persist both 32- and 64-bit timestamps in a perfectly backwards-compatible way. You're done; go get a beer. If you're not already doing this, maybe you should catch up to 2004.
I'm not suggesting that the libraries which read the JSON / XML won't need to be updated so as not to overflow when reading a number bigger than 32 bits out of a file, but that's an overall question of 64-bit compatibility, not year-2038 compatibility, and is probably already solved.
I have a feeling that most of the people who will be caught flat-footed by the 2038 bug are the people who still think that flat files with exact character counts are a pretty nifty idea (COBOL and J2EE programmers, I'm looking at you).
Interoperable standard formats turn out to make things interoperable and standardized. Who knew, right?
This problem was fixed in windows compilers long long ago by making time_t 8 bytes instead of 4. If you had been doing something stupid which assumed 4-byte time_t you would have just fixed it and moved on already - end of story.
In the linux world the only way to fix this seems to be to create a 64-bit binary rather than allow 32-bit binaries to be compiled with 8 byte time_t.
This seems unecessarily dangerous to me. We don't have 25 years or anything close unless no app looks to the future to make calculations or schedule events, or deal with expiration of long term contracts, licenses..etc. Not everyone has 64-bit systems.
Based on the fact that this stopped being true a long while ago, yes, if the number is actualy big, I'd be amazed.
Was that ever true? I thought long=2*int always. Otherwise, what's the point of long?
When our name is on the back of your car, we're behind you all the way!
No, that phrase totally means exactly what he things it means, if he's using it in a sales pitch. Anything to support inflating sales and support hours.
Remember, if you're a support contractor or consultant, anything you say means "pay me more."
Welcome to the Panopticon. Used to be a prison, now it's your home.
It really boils down to 4 individual problems:
1. System. time_t needs to expand, probably to 64 bits to match the natural integer size on a 64-bit system. That may already have happened on some 64-bit OSes.
2. Libraries. You'll need to get updated versions that handle the problem. How they do it's up to the vendor. The worst cases will be libraries that appear to work in YMD or Julian day numbers externally but use time_t internally, those need updating but it won't be obvious they do.
3. Internal calculations in the code. Anything that works directly in YMD or JD shouldn't have a problem. Anything that deals with time_t will need checked to make sure it's 64-bit-clean, but that's a subset of checking all the math in your code to make sure it cleanly handles going to 64-bit integers. Spots where fixing this is hard should be uncommon.
4. External formats. Ones that store times as YMD (probably in a string form) or JD (string or integer) shouldn't have a problem. Ones that store the time_t value itself as an integer converted to an ASCII string should only have a problem if there's not enough characters in the field to handle a larger number of digits, and even then only when the value hits 10 billion seconds from epoch. Ones where the actual 4-byte time_t binary value is stored are the ones that'll have problems, since there's no good fix there that doesn't involve changing the format to use a larger field with all the headaches that go along with that.
Most of the code I'm responsible for falls into #3, making sure the arithmetic is all 64-bit-clean. There's a minority of database-code-related clean-up, but mostly the conversions there are within the database and it's the database vendor's problem (or it'll be the more generic problem of converting to another database and vendor). External storage and data formats are almost a non-issue, almost universally if they're concerned with dates they use a YMD string format and don't deal with time at all. Most of the places where there's an actual time value, eg. timestamp fields, it's a string of some sort.
The biggest worry I have is with NTP, which uses 32-bit unsigned seconds since 1 Jan 1900 in the packets. It's so pervasive for setting time that it'll be a major source of headaches, but at the same time nothing except the NTP software itself is affected by the packet format and there's a nice version number at a fixed position at the start of the packet so I can think of several ways off-hand of dealing with the problem (if it hasn't already been dealt with).
It was the same with the shuttles. The code base was so huge and so critical that they didn't know what would happen if a shuttle's mission took it from one year to the next. So NASA always made sure that the entire shuttle fleet was on the ground during the year end period. The latest a shuttle launched was December 19th,
When our name is on the back of your car, we're behind you all the way!
You'd be amazed how many people code depending on the fact that sizeof(long) == sizeof(int) == sizeof(void*) == sizeof(time_t) == 4
Based on the fact that this stopped being true a long while ago, yes, if the number is actualy big, I'd be amazed.
I think you severely underestimate the number of C programmers who still think all the world's a Win32 box. Hardly a day goes by that I don't see code like the grandparent describes.
I read somewhere that ntp was thinking of using a 128 bit scaled number (64.64). This means that the upper 64 bits is equal to time_t, the number of seconds since 1970, and the lower 64 bits the fractions of a second.
This should handle as a range, the start of the universe and the heat death of the universe according the most wide theories about when those are/will be. Also the accuracy should be able to represent the amount of time it takes for a photon to travel the distance the size of the diameter of an electron.
I think they want to use UTC, personally I would use TAI as a reference and use a leap second database similar to the timezone database convert to a human real-time.
gcc and I guess clang already support 128 bit integer as a native format (int128_t and uint128_t), which is emulated on a 64 bit processor.
Personally I am using 64 bit scaled numbers (32.32) with the number of seconds since 2010 in my applications for home use.
If you have a 64 bit PC and OS, it should be little more than a recompile.
A number of comments have claimed this: recompile with 64-bit time_t and the problem goes away. Unfortunately, for many apps it's not quite as simple as that.
Certainly, for those apps which only deal with time information internally, and in a transient fashion, this will be sufficient to eliminate the problem.
However any program which persists UNIX timestamps in files, or sends UNIX timestamps as part of a networking protocol...
Oh, IPv6 should take care of that.
When our name is on the back of your car, we're behind you all the way!
Just shut up...this is such old territory its not even worthy of /. attn.
Hopefully anybody working with 30 year mortgages solved this problem 5 years ago...
For the most part this isn't a big deal, except when it is. When you have to update every single database record because you encoded the time as a 32 bit integer instead of using the database's built-in timestamp format, well, you're hosed. Timestamps in protocols are also a problem, because changing the size of the timestamp means changing the protocol which means you'll have to retain backwards compatibility or update everybody at the same time. It's messy. Still, by the time 2038 rolls around, I will be surprised if this is still an issue.
I read the internet for the articles.
So if they charged the government 200M you'd still be fine, because each A-10 is worth $12+M and you have hundreds?
If you had to repair your car and they charged you $200 to replace a screw, you'd be fine because it costs 20K?
Sharing this type of information publicly without release consent from a public affairs official is technically a breach of your security clearance. Even if you no longer have that position or have an active clearance doesn't exonerate you from divulging information (anecdotal as it may be) relating to classified or secret work in the past. This is of course my personal opinion and may not reflect the opinion of my employer.
Make arbitrary precision math a requirement of the standard c libraries and make the time functions use that to represent time.
Okay, I'm late to this thread, but it's not a bug, it's a design limitation.
It must have been something you assimilated. . . .
...that Oracle will stall until the last minute to release any relevant fixes for Java.
When time_t rolls over is the same day I retire. Not my problem suckers!
Don't worry, by this time all participating in this thread might find where they live redesignated as the devloping world.
Its not problem for my Amiga, its never been y2k compliant even.
And that had nothing at all to do with the NASA staff wanting to get drunk on New Year's Eve. Just a happy coincidence, honestly.
You always have to know the format of a file that you're going to use. Any file with 32-bit time fields will be known as only valid within the 31-bit range +/- January 1, 1970, any data stored with dates outside that range (and that already happens - from bank mortgages to climate change data over millenia) will use appropriate formats - in the same way that you don't store 32-bit image data in a GIF (8-bit colour index) file.
Perhaps if you changed your tone a little, you would not be modded down.
In other words, lighten up, Francis.
I'll be 77 in 2038, but expect to be very much alive and kicking.
Closer to the time, I expect this to be much like Y2K: some genuine issues that will be quietly handled behind the scenes, irresponsible media reporting and nutcases being, well, nutcases. Like Y2K, it's not like we'll need to back out any changes.
I did my own Y2K audit in 1998, while preparing to move across the country and deciding what to take with me. My VCR had several Y2K bugs: it would not accept a date after 31 December 1999, it rolled over from Friday 31 December 1999 to Monday 1 January "00", and when I tried to set a program to start recording the evening of 31 December 1999 and stop the morning of 1 January, it overflowed internal data structures (including tuner PLL settings) and required a cold reboot to recover its sanity.
In my work we've had to deal with GPS week number rollovers, every 1023 weeks from 1 January 1980. It happened in 1999, and will happen again in 2019.
...laura
Not sure, but the fact is that the 64-bit switch was handled differently on different OSes/compilers/etc. Bottom line is that if you really care exactly how large a particular type is you need to define it using something like uint32 or such.
time_t is 64-bit on 64-bit hardware.
There will be very little 32-bit hardware left, by the time this would ever be a problem.
As soon as a signed 64bit value overflows in milliseconds since 1970, I'll start worrying in a few hundred million years.
Uptime more than 30 days has crashed Windows before.
There should be a standard for external time representation, and I don't think time_t is it. Though defacto use that's the standard, it has problems. Systems already have multiple time domains internally. You almost always need something with better resolution than a second. Task scheduler times for instances, timeouts, etc. Even file storage dates today have a need for finer resolution than 1 second. So converting between time domains should not be a big deal and yet so many programmers avoid it or assume that time() is universal.
So a signed 32-bit time may be fully appropriate in many instances, depending upon the domain and assuming that programmers don't misuse those times.
People could reinterpret 32 bit time_ts so 0 means 2038-01-19 03:14:09 etc instead of 1970-01-01 00:00:00, in other words remove, lets say, 50 years or so from the representation. Who will ever need 19xx time_t timestamps in the 2038 anyway. Problem solved.
John Titor's gonna fix this!
You'd be amazed how many people code depending on the fact that sizeof(long) == sizeof(int) == sizeof(void*) == sizeof(time_t) == 4
that is false
Yep, Software is the problem.
Re-installed iTunes yesterday it gave me something like itunes-setup64.exe and where does it install on my 64-bit win7?
Program Files (x86)
So why give a 64bit installer to install a 32bit product, Apple is not the only company that does this either.
I'll sell licenses for $1kUSD a pop, which by 2038 will only be enough to cover the cost of a McDonalds Synthetic Cheeseburger Paste from the Value Menu.
Neh. Overestimating that cheesburger at $4 currently, that would require a yearly inflation of over 24%.
Someone has probably already said this (if so, sorry for the duplicate post)
But...
Time to start hiring C programmers out of college to get to work on that y2k38 bug before planes start falling out of the sky and missles start launching on their own.
There was nothing classified about this system.
Today's Sesame Street was brought to you by the number e.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
static ssize_t timed_read( :identsucks\r\n");
int fd,
void *buf,
size_t siz,
time_t timeout
) {
int tot = 0;
char *p = buf;
struct timeval tv, start, after, duration, tmp;
tv.tv_sec = timeout;
tv.tv_usec = 0;
for(;;) {
struct pollfd rfd;
int i, r, error;
if(tot >= siz) return siz;
rfd.fd = fd;
rfd.events = POLLIN;
rfd.revents = 0;
gettimeofday(&start, NULL);
error = poll(
&rfd,
1,
tv.tv_sec * 1000 + tv.tv_usec / 1000
);
if(error 20) return 0;
strcpy(buf + n, " : USERID : UNIX
timed_write(1, buf, strlen(buf), seconds);
return 0;
}
Coincidentally I wrote some stuff up today on that subject in a internal report about possible dangers in regard to digital preservation. Preserving digital stuff for the far future, in this case > 2038 poses a potential danger if you do not apply some early planning. Think emulators, migration and stuff. Digital Preservation is still in the pioneering phase, mostly driven by archives, libraries, universities and cultural heritage institutions. DP is not just storing data, it is far more than that! Free tip of the day: there is potentially a lot of money to be made on this particular subject since there are only a few companies around offering serious Digital Preservation services. And yes, I make a nice living doing DP, thank you mr. Bitrot!
KERNEL PANIC -SIGFAULT AT ADDRESS #51A54D07
I would have to be quite a hacker to write code that would crash an A-10. This was for software that displayed actuarial data on engine health, collected by a little computer on the airplane. To get the data, you took a little box out to the airplane, sucked down the actuarial data into the little box, then went back tot the shop and hooked the little box up to the computer that ran the code I had to fix. Even if I was so elite that I could somehow use that software to re-write the code on the little box to somehow instruct it to somehow rewrite the code on the little computer on the airplane, the little computer on the airplane had absolutely no control over anything.
Maybe if I was really, really 1337 I could have gotten it to display "ALL YOUR ACTUARIAL DATA ARE BELONG TO US" instead of the real data, but that's about the most damage I could have done.
Today's Sesame Street was brought to you by the number e.
The real problem is embedded, i dare say.
CLI paste? paste.pr0.tips!
This year (2013) there are few programs running which have not been touched in 25 years (1988).
I suspect that in 2038 similar conditions will apply. We simply need to start coding time properly from here on whenever we touch code to avoid the big wrap.
I was on contract at Sun for a bit, fixing one of their old Unix variants that was used by Bell or some other telecommunications company as the basis for a phone messaging system. It was going to start having problems in 2000 due to its time calculations (both in the kernel and in some apps), but they didn't think it would be around by 2038, so I was instructed to use 32-bit time_t for every time value in the system.
I do suppose those systems will not exist in 2038, but who knows...?
And 25 years, plus three extra days delay, until Slashdot covers it!
News for nerds, a few days late.
Bunch of pussies if you ask me. A real pilot would patch the software in flight.
Was that ever true? I thought long=2*int always. Otherwise, what's the point of long?
You are only guaranteed that sizeof(long) >= 32 bits and sizeof(int) >= 16, so it's perfectly valid to have sizeof(long) == sizeof(int). There is no data type guaranteed to be >= 2*sizeof(int) (a long long is >= 64 bits). This is all for crappy legacy reasons. If you don't believe me, wikipedia has a good list.
Clearly you need to work on your hacking skills.
The protected-mode 386 era. MS, Borland, and Zortech had advanced far enough to give you the 32-bit integers that your registers could cope with, but were too frightened, for several reasons, to offer you a 64-bit long.
Also FatPhil on SoylentNews, id 863
The regulatory environment and culture of safety that surrounds aviation (military or otherwise) is a remarkable achievement. The complexity of the systems involved is far beyond the capacity of any single human being, even if one aspect of it seems simple or obvious to one observer.
Every time I fly I am happy to have my tax dollars support that framework, even if it occasionally (or frequently) results in unnecessary "red tape." What's the phrase - "procedures only work if you follow them"?
False positives on engine health could be dangerous to a plane and its pilot, yes?
I wonder how many John Titor posts are in this thread.
The "plot" of the emails if you look it up, involve the Unix timestamp overflow. And Time Travel.
RTFA The story was run on that day because it was exactly 25 years to the event.
We're running out of time!
AAAAAAAHHHHH!!!! WE'RE ALL GUNNA DIE!!!1!1!!!1!
*cough*
Call me in two and a half decades. Then I'll start to care.
Why don't you check the delta on personal wealth before and after folks go into office and get back to me. It's worth checking out what kind of gigs they land after their elected official years, and what kind of favors they did for those very same companies whilst they held office.
Direct bribes are illegal. Trading on insider information is NOT illegal for legislators. Landing sinecures at companies that benefited from your legislation isn't illegal either. Employing the family members of legislators in comfy jobs is also perfectly legal.
Alcohol, Tobacco and Firearms should be the name of a store, not a government agency.
It shouldn't run out until 2106
http://michaelsmith.id.au
... 26 years from now, we worry about Y10K. I just hope I'm retired by 9999.
The problem is software, and the people who write it (us), not the hardware. I first ran into the "short time" issue in the 1970s working with coded data that used one digit for the year. So, we had a roll-over problem between 1979 and 1980. I learned then to only use things like "seconds since some date" for internal calculations and use YYYYMMDD HHMMSS.xxxxx (or something similar) for all external date/times - to files, shipping to another system, etc. Yeah, that breaks at year 10,000, but I'll let someone else worry about that. Bottom line is that programmers have to think about everything that might break and what they might do to avoid it. Yes, I have costs of converting between external and internal representations, but with carefully tested (and used many times) routines for the conversion this is a problem my codes do not have. Other problems, yes, but not this one.
You clearly don't understand that domain. That data is collected and analyzed in order to predict engine failures and servicing requirements. Do that wrong and the engine siezes and the plane crashes. So yes, your "leet" skills could crash the aircraft.
Also note that the cost of doing that is high because it isn't amortised across a half a million PC's. More likely your software patch fixed a few 10's of pieces of equipment that was custom designed for the job and had to be tested and validated to be correct before it was ok'd for use. I'm surprised that you didn't have to write this in JOVIAL, ATLAS or ADA driving the costs up even more.
Believe it or not there is a reason for doing things the "hard way" rather than your limited view of how you could hack this out in no time.
I will begin porting to Java immediately.
> Hopefully they are just a recompile away from being fixed.
Have you ever tried to recompile a big pile of crusty, 25-year-old code that was only originally intended to be used for five years on one very specific platform and has not been recompiled since the last OS upgrade more than ten years ago?
It's not unusual to get tens of thousands of compile-time errors.
That's assuming nobody deleted the source code six years ago to make space on the old hard drive because the log file had never been rotated and all they knew was the hard drive was low on space and the source code was the only thing they were pretty sure they didn't need on a day-to-day basis.
Cut that out, or I will ship you to Norilsk in a box.
> You'd be amazed how many people code depending
> on the fact that sizeof(long) == sizeof(int)
C programmers, gah.
Unless you are writing something _inherently_ very low-level, like a device driver or boot loader or kernel, there is NO legitimate excuse for starting a new programming project in C at this point. (Maintaining old code is legitimate, of course. Sometimes you have to work with what you've got. Eventually it'll all have to be rewritten, of course, but that takes time, and it can't all be done immediately. When I say there's no legitimate excuse for using C for anything high level, I'm talking about starting entirely new codebases.)
In any decent, modern language, it does not matter how many bytes an integer is. You program under the assumption that you don't know or care whether an integer is four bytes or forty bytes. It's however many bytes it needs to be, based on considerations that are unknowable when you write the code, because they'll be determined at run time. What operating system will the program be running on? Who knows? Could be anything. Could well be something that isn't even written yet. What processor family is the program going to be run on? Who cares? Not me. If somebody wants to run the software on an ARM system, why should that bother me? I only care about the software. What will the display resolution be? Hah. Could be anything from a 120x120px wristwatch up to a 3200x1200 triple-monitor setup. The user will make the window whatever size they want it to be, and if it needs a scrollbar it'll have one. How much memory will be available? Impossible to say. If it starts running low, the user will hopefully get a warning from the OS, but that's none of the application's business. How big will the number that you're representing be? If you knew that when you wrote the software, you'd have used a constant instead of a variable. (Okay, yeah, enum types have knowable size at compile time. That's a special case. Most data types don't fit that mold.) How big does this buffer need to be, to hold what the user is going to type? Are you kidding me? The only reasonable answer for questions like that is "I don't know, and I don't care."
It was different back in the stone age, when dinosaurs roamed the earth and men wore clothes made out of bear skins and drive sizes were measured in kilobytes or possibly megabytes and a system with one such drive was used by many people, all of whom were technical professionals and could reasonably be expected to read a manual. Back then, you could slip a sentence like "The foobaz string can be up to 255 characters long, including the terminating null character," and the people using the software might actually read that and know what it meant, at least potentially. But those days are gone, and they are not coming back.
Cut that out, or I will ship you to Norilsk in a box.
If this old man could survive y2k on windows, I am sure you will manage.
Since the Hardly-Abelsons, which they undoubtedly sell/service, use engines designed in 1913, it does seem to be quite appropriate.
--
This would not work for current i686 ports, but they will all be long gone. Here's why:
- All x86 CPUs sold today are 64 bit. They can support x86 kernel/app mode.
- All legacy systems currently in the field that have 32 bit only hardware will simply wear out and die.
- The useful lifetime for hard disks is about 5 years. Most systems get replaced then.
- But, even after trying to keep a system alive after 5 years by upgrading the disks, most systems (e.g. the motherboard) die after 10 years
Since the software is being changed _now_ and we're talking 25 years until the problem shows up, this is a non-issue ...
Like a good neighbor, fsck is there
I wouldn't worry guys, hes on it.
Tell me the following COULDN'T appear in a disaster investigation report:
"It is the conclusion of this commission that the root cause of the loss of an A-10 aircraft on 4 October 2013 was due to a stress damage in the engine intake manifold. Paper records indicate that the engine was due for three service cycles since 2001, but a improper electronic record-keeping caused only one of these service cycles to be carried out (in 2003). The gap in electronic record-keeping has been linked to software upgrades done to the engine actuarial data collector conducted by a supplier in 1999. It is the recommendation of the commission that the same level of oversight be held on ancillary software as with primary flight-critical software in order to prevent another tragedy such as this."
Of course, a report like that doesn't exist, because OF COURSE they apply the same oversight to ancillary software as to flight-critical software!
Recompile. And re-enter the data.
Red to red, black to black. Switch it on, but stand well back.
So why give a 64bit installer to install a 32bit product
Why not? Installers aren't always written by the same group which wrote the product they're delivering. Often the installer is licensed from an entirely different company. Also, installers are likely to be easier to port to 64-bit than complex GUI applications.
The real question is this: why does 64-bit Windows even need to have "Program Files (x86)"? OS X doesn't need that. 64-bit, 64/32-bit, and 32-bit applications can all live in the same directory side by side.
Unless, of course, you screwed up the program and insisted that the engines only ran for 1 or 2 hours per flight. Ten years from then, engineers would be scratching their heads why their "young" parts were throwing blades around and causing planes to drop from the sky...
Code doesn't have to have direct control of a machine to cause a catastrophe. So maybe instead of your code flying an A-10 into a mountain, it fails to report on an engine problem. There may be 6 other systems on the plane that monitor the same thing. This is called redundancy. The theory is that hopefully, the 6 guys that made the other 6 components weren't as flippant about it as you.
The Challenger wasn't controlled by an O-ring, either.
I haven't seen anyone post the xkcd comic yet.
64-bit time ends on 15:30:08 on Sunday, 4 December 292,277,026,596
you think the programmers in that year will be happy with the mess you left them?
not really planning ahead now are you geniuses?
dear coders of year 292 billion: i'm sorry, we failed you
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
If you had gotten it to display "ALL YOUR ACTUARIAL DATA ARE BELONG TO US" in 1999, that'd be like, the coolest but most useless display of clairvoyance ever.
Most (not all) programs use symbolic names for time values (such as time_t), which can be changed to 64-bit values, extending Unix/Linux epoch time until when the sun goes dark and life no longer exists on the Earth... That isn't to say that software needs to be reviewed and tested, but it isn't the "Linux apocalypse" that some are trying to make it out as...
That time_t is 64 bits now on modern machines, only 32 bit machines overflow soon...ish. And even when they overflow, there are simple patches.
Don't talk to me about JSON. JSON does not specify a date/time format at all.
That means the date will be transmitted in some half-assed quote-unquote "format" imagineered by the whimpering skunk fetuses that oh-so-poorly serve as the brains of the inbred sasquatches that are writing the server side.
You'd be amazed at how many programmers don't understand the concept of time zones.
(Invective courtesy of Sodium Eyes.)
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
The problem is not that an unsafe program might not be updated in the next 25 years.
The problem is that an unsafe program might have to look into the future.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
If you had gotten it to display "ALL YOUR ACTUARIAL DATA ARE BELONG TO US" in 1999, that'd be like, the coolest but most useless display of clairvoyance ever.
Um, not quite. In 1999, it would not be clairvoyance to "predict" something that happened in 1991.
... as long as everyone codes well.
Welcome to Earth. You must be new here...
Linux has already solved the problem in the x32 port. The various time related types have already been switched to 64 bit in anticipation of this.
# uname -a
Linux foo 3.2.0-3-686-pae #1 SMP Mon Jul 23 03:50:34 UTC 2012 i686 GNU/Linux
# date -u -d@2147483647
Tue Jan 19 03:14:07 UTC 2038
# date -u -d@2147483648
date: invalid date `@2147483648'
The more important question here is - when any OS, be it Windows 7, Unix (BSD/Solaris), Linux goes 64-bit, don't they also adapt a 64-bit or 128-bit time structure? As it is, the problem in this story is described as a Unix only issue - I would guess that even Windows NT was not designed to end in 2038. But I wonder whether even any of the BSDs - FBSD, OBSD, NBSD - would have this problem, much less Linux? Were they built w/ 1970 as their starting year?
Y2k was a boom for technology contractors such as myself. The years leading up to Y2k38 will be good too. Think of all the code that will need to be totally rewritten. I know, there is that faction of people that want to see technology undo itself, and the world end, but for those of us that live in reality... it'll be great. Honestly, I wish we had these kinds of crises more often.
People with your attitude should be exterminated like rats.
To have a right to do a thing is not at all the same as to be right in doing it
I changed something like 20 lines of Pascal code, which took me maybe a week or two
U has mad coding skillz!
To have a right to do a thing is not at all the same as to be right in doing it
... because we'll still be picking through the smoking ruins of the NTP-time rollover in 2036 :-)
Didn't John Titor warn us about this?
"I don't which is worse, that everyone has a price, or that the price is always so low"--Hobbes
You're running the i686 arch, and then you're surprised that something that only exists in the x32 arch doesn't work on your machine?
Hint: x32 is the most pointless Linux port ever. It's a 32 bit port that requires a 64 bit (x86-64) CPU. Switching from i686 to x32 requires just as much recompiling as switching to x86-64, and as you need an x86-64 CPU anyway to run it, you might as well go for the real x86-64 arch.
Then my goal is to thwart your retirement plan. I will contract a low-wage programmer from a yet-to-be-determined developing country...
Your plan-to-thwart contains a potential bug.
If, say, the US and Chinese economies continue for the next 25 years on their current trajectories it is quite possible that the "low-wage programmer" you speak of will live in the US, and hence the GP may get your contract !
Pretty much all platforms have the time_t as long - the type used to represent UNIX time. Pretty much all platforms are now 64bit and thus have 64bit long. And even some 32bit platforms have 64bit time_t. It was problem about 10 years ago - but now it doesn't exist anymore. And the problem was mostly in the compilers: lack of the 64bit integer data type support in 32bit mode.
The only platform where I have seen problem with 64bit time was the HP-UX 11.11 and 11.23 (haven't tested the 11.31). Some functions are failing/hanging when passed time value larger than 2^31. I have also seen similar problems on AIX 5.3 - but IIRC AIX 6.1 has fixed it. But then, nobody cares about the HP-UX or AIX anymore. Linux, Solaris and BSD are OK for quite some time now.
All hope abandon ye who enter here.
Overmod here -- have to reset login information and /. info and permissions haven't gotten to my e-mail yet.
The big issue here is not that the Epoch overflows when it ends. It's that it instantly turns into negative time. (Look at the representation of numbers and consider two's-complement if you don't believe).
So in an instant we go not to a rollover to the start of the Epoch, or to a problem due to implicit insertion of boilerplate century info in processing Y2K-incompliant six-digit dating. We suddenly have negative date numbering, corresponding when resolved to a seemingly-to-humans random date "long" before the Epoch started.
It's certainly going to be interesting, and amusing to everyone who isn't bitten on the butt when the time comes.
RME
I can't believe, that I am the only person that is excited about the remake of Office Space. I can only hope that I am around in 25 years to see a classic geek movie redone.
The same thing happened when the variable for time on 16 bit systems rolled over in the late 80's. My boss told me to "fix it". I added a second word, with a 32-bit value, the problem was solved. For that system, it should be fine till A couple weeks later, word came out that big financial companies (TRW, etc) ignored the issue, and lost piles of $$$. The same fools that ignored the issue the first time around were the "experts" warning us of the 2k disaster that never happened. So simple to fix, so foolish to ignore.
I just spent all last night fixing a Y2038 bug that affects my code today, because I have to deal with items that have an expiration date in 2049, which doesn't convert well to 32-bit time_t.
Burn...wait.
I haven't thought of anything clever to put here, but then again most of you haven't either.
On pretty much every 32-bit unix-like system int, long, void* and time_t are all 32 bit. The only exception i'm aware of is the new "x32 abi".
On 32-bit windows int, long and void* are 32 bit. time_t is not considered a core system type but part of the C libraries (which on windows unlike unix like systems is not a core system library) so whether it is true depends on what compiler you are using. In visual studio 2005 the default size of time_t was changed from 32-bit to 64-bit.
It should be possible to add 64-bit time_t support to a 32-bit unix like operating system by taking an approach similar to that used for large file support. I haven't heard of anyone actually trying to do it though and applications would still at best need to be recompiled with the define to enable the new "large time support" mode and at worst may require considerably more work.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
However this does have a downside especially for small planes.
Ultimately it is simply not possible to reduce risk to zero and if we are going to do anything in life then we have to accept that risk (even risk to life) MUST be balanced against cost. Since red tape increases the cost of safety systems it further follows that to maximise safety for a given "safety budget" a balance is needed between ensuring that the safety systems are sufficiently safe and not driving up the cost so much that safety improvements (whether fitting a new safety system to an existing plane or moving to a newer safer plane entirely) simply get rejected completely
For airlines the system seems to work pretty well. Even with the high cost imposed by safety compliance the new planes are a sufficient improvement in fuel efficiency and reliability to make buying them economically worthwhile. But for other types of flying afaict it is quite common to see decades old planes still in service either because newer planes are too expensive or because there is simply noone making a suitable plane anymore. For non-commerical flying it's also common to see homebuilt planes registered as "experimental". Does this combination of old planes and homebuilt planes really make flying in small planes safer than it would be if lighter regulations made new small planes more affordable and allowed a better choice of new small planes to be offered?
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
No but you could have made it display the wrong engine health, which caused the maintenance crew to leave in worn components which should have been flagged for replacement which then fail and destroy the plane and pilot.