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.
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.
"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.
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!
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
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
I don't see why we'd need 128-bit time if we're counting seconds, considering that 64-bit time gets us up to 20 times the current age of the universe (meaning that 95% of the possible negative timestamps aren't just unused, but unusable if our current understanding of the laws of physics is correct).
I really wanted to change my sig to something witty, but all I could come up with is this.
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).
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.
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
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.
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
You think you feel silly? Imagine how the Mayans felt!
Think of all the code that will need to be totally rewritten.
I don't think that phrase means what you think it means...
Probably laziness. You need an integer variable, you just use int without thinking about whether the value might ever go negative or not. This probably happens all the time, but it is extremely rare that it actually becomes an issue. After all, a signed int can store a number up to just above 2 billion - how often do you need to store numbers even approaching that big? The same thing happened in World of Warcraft with gold. For a while, the gold cap was (2^31)-2 copper (which translates to 214,748 gold, 36 silver, 46 copper) - which indicates they used a signed int despite the fact that it's impossible to have a negative value of money in the game.
At some point (I'm not sure exactly when, but I think it was during the Wrath of the Lich King years), they changed it to use a 64-bit value, and the gold cap is now 1 copper shy of 1 million gold. That was an artificial limitation - there's no real reason why they couldn't just use the entire 64 bits if they wanted to - I don't think anyone would ever be able to reach the 2^63 (assuming a signed 64-bit integer) that it could store.
Intelligent responses welcome, flames will be met with marshmallows.
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
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.
2038 is so close to the singularity that the computers will most likely just fix it themselves.
2147483647 (INT32_MAX) seconds / 60 /60 / 24 / 365 = ~68 years. 1970 + 68 = 3038. 1970 - 68 = 1902.
Do you even lift?
These aren't the 'roids you're looking for.
"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.
Contrary to what the cultists of unsigned int(time_t) implementations might tell you, there was in fact time before 00:00:00 1 January 1970. Its vast (but often boring) history is chronicled in records made of ink symbols impressed on sheets of processed wood pulp bound in volumes known as "books".
0 1 - just my two bits
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.
I don't see why we'd need 128-bit time if we're counting seconds, considering that 64-bit time gets us up to 20 times the current age of the universe
Moving to 128bits, you would definitely no longer count in seconds but probably in 1 millionth or 1 billionth of a second. Or even finer resolution then that (use the lower 64bits for sub-second resolution).
Wolde you bothe eate your cake, and have your cake?
And just who are you to tell me it's too early to panic? I'll panic when I want.
Why can't you have dates before jan 1st 1970?
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.
Sure it does, at least on 5.3.10-1ubuntu3.4.
It's unsigned integers it lacks, for whatever reason...
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.
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!
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?
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!
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
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!
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!
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.
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.
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.
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.
As soon as a signed 64bit value overflows in milliseconds since 1970, I'll start worrying in a few hundred million years.
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.
John Titor's gonna fix this!
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.
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!
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...?
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.
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"?
RTFA The story was run on that day because it was exactly 25 years to the event.
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
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.
> 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.
--
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
Recompile. And re-enter the data.
Red to red, black to black. Switch it on, but stand well back.
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
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]
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
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.
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.
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