×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

You've Got 25 Years Until UNIX Time Overflows

timothy posted about 2 years ago | from the start-packing dept.

Bug 492

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."

Sorry! There are no comments related to the filter you selected.

Could we be a little less biased? (5, Insightful)

damn_registrars (1103043) | about 2 years ago | (#42656767)

those phony programs politicians use to project government expenditures

The programs are real, even if the math may be phony.

Re:Could we be a little less biased? (5, Insightful)

Anonymous Coward | about 2 years ago | (#42657267)

History shows us that it's not biased in the slightest to assume that politicians will lie, cheat, and steal their way to riches. Giving them the benefit of the doubt is like Charlie Brown giving that field goal one more shot because maybe, just maybe, Lucy won't pull the ball this time.

Re:Could we be a little less biased? (2)

Archangel Michael (180766) | about 2 years ago | (#42657315)

Most Insightful Post Ever!

Re:Could we be a little less biased? (2, Funny)

Anonymous Coward | about 2 years ago | (#42657381)

History shows us that

Blah blah blah. The parent was not giving anyone the benefit of the doubt. And just FYI the whole football thing was an analogy for sex.

As for the article, I'll sum it up for everyone: "Y2K is coming to get youuuuuuuuuuuuuuuuuu!!!! Hide the children!"

Not NetBSD (5, Informative)

Nimey (114278) | about 2 years ago | (#42656775)

NetBSD has switched to a 64-bit time_t.

Re:Not NetBSD (4, Insightful)

Beezlebub33 (1220368) | about 2 years ago | (#42656811)

64-bit is taking over already everywhere. In 10-15 years, you will have a hard time finding a 32-bit computer. (Actually, you might have a hard time finding a 'computer' at some point but that's a whole other issue). With the change to 64 bits, more and more OS's will operate on 64-bit time, and this will not be an issue.

Re:Not NetBSD (-1, Flamebait)

Anonymous Coward | about 2 years ago | (#42656867)

That's not how it works, you dumb shit. Are you trying to say that "64-bit computers" don't have any support for 32 bit integers? The size of the variable the OS uses to store its time value has nothing to do with the memory space it's capable of addressing.

See my post below:
developers.slashdot.org/comments.pl?sid=3399939&cid=42656827

You prove my point. STOP POSTING.

Re:Not NetBSD (-1, Offtopic)

djsmiley (752149) | about 2 years ago | (#42657003)

That's not how slashdot works you dumb shit.

STOP POSTING.

Re:Not NetBSD (5, Informative)

mrjatsun (543322) | about 2 years ago | (#42657083)

> Are you trying to say that "64-bit computers" don't have any support for 32 bit integers?

The issue is if time_t is a 32-bit int or a 64-bit int. Not if a bit-64 CPU supports 32-bit integers.
time_t is generally defined as a long across OS implementations.

In the 32-bit ABI (Application Binary Interface) for most (all?) OSes, a long is a 32-bit value.
In the 64-bit ABI, a long is 64-bits, so the 2038 time issue does not exist for 64-bit apps.

So if you are running a 64-bit app, you don't have a problem in that app. One solution is to
not support 32-bit apps anymore. i.e. you don't support the 32-bit ABI in your 64-bit kernel.
You can do this easily in linux today (e.g. gentoo, 64-bit only support).

Another solution is to break 32-bit compatibility (or to define a new 32-bit "ABI") which
changes the definition of time_t (and some other system types) to be a [u]int64 instead
of a long.

So, *if* the parent was suggesting don't support 32-bit apps, then they were right ;-)

Re:Not NetBSD (0)

Anonymous Coward | about 2 years ago | (#42657379)

The time_t was, in many cases, switched to 64bit even in 32bit OSs.

Re:64-bit computers DO NOT solve this problem (4, Insightful)

JcMorin (930466) | about 2 years ago | (#42656879)

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.

Re:64-bit computers DO NOT solve this problem (4, Insightful)

h4rr4r (612664) | about 2 years ago | (#42656963)

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.

Re:64-bit computers DO NOT solve this problem (5, Insightful)

locofungus (179280) | about 2 years ago | (#42657215)

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.

Re:64-bit computers DO NOT solve this problem (5, Funny)

HaZardman27 (1521119) | about 2 years ago | (#42657411)

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.

Re:64-bit computers DO NOT solve this problem (1)

cshark (673578) | about 2 years ago | (#42657423)

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.

Re:64-bit computers DO NOT solve this problem (2)

Hatta (162192) | about 2 years ago | (#42657119)

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.

Re:64-bit computers DO NOT solve this problem (0)

Anonymous Coward | about 2 years ago | (#42657193)

True. Don't recompile and continue whining.

embedded (5, Informative)

Anonymous Coward | about 2 years ago | (#42657283)

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).

Re:Not NetBSD (4, Informative)

petermgreen (876956) | about 2 years ago | (#42657319)

The problem is not so much the OS, as you say most systems will be running 64-bit operating systems and even 32-bit operating systems will likely find a soloution (like was done for large file support). The problem is the applications which have the assumption of 32-bit unix time built in.

You might say "just recompile for 64-bit" but that assumes that

1: you have the source
2: the source is not full of assumptions that make rebuilding for 64-bit impractical
3: the source actually stores the time in variables of type time_t or long and not variables of type int or type int32_t.
4: the data files the program stores on-disk do not include timestamps in unix format in fixed size fields.

For what proportion of applications do you belive all four of those assmptions will hold.

Re:Not NetBSD (1)

Anonymous Coward | about 2 years ago | (#42656905)

And your point is?

#include <ctime>
#include <iostream>

int main()
{
                std::cout << "The time_t on Linux is " << sizeof(time_t)*8 << " bits.\n"
                                          "HTH\nHAND\n";
}

Gives:

The time_t on Linux is 64 bits.
HTH
HAND

Re:Not NetBSD (2, Informative)

Anonymous Coward | about 2 years ago | (#42657171)

AFAICT, Linux typedefs time_t to long, which will be 32 bits on 32 bit systems and 64 bits on 64 bit systems.
There shouldn't be too many 32 bit desktops around in 25 years, but I can easily imagine some long forgotten embedded systems starting to act funky.

Re:Not NetBSD (1)

mgcleveland (2029194) | about 2 years ago | (#42657107)

The problem is with systems already deployed and legacy systems still running on 32-bit OSes, not those that have switched over to 64-bit architectures.

Re:Not NetBSD (1)

gweihir (88907) | about 2 years ago | (#42657211)

At least 64 bit Linux has too. The only 32 bit installation I have (on a Raspberry Pi) has not.

Re:Not NetBSD (1)

WilyCoder (736280) | about 2 years ago | (#42657257)

Don't forget the Rpi doesn't even have a real time clock...

Re:Not NetBSD (1)

gweihir (88907) | about 2 years ago | (#42657371)

Yes, I know. A limitation found on quite a few other embedded systems. My intuition is that on something without real-time clock, this issue cannot be important.

That's OK (5, Funny)

Big Hairy Ian (1155547) | about 2 years ago | (#42656793)

The IOS reminder service will fail for the first week in January atleast once before then :)

Come on! (0)

Anonymous Coward | about 2 years ago | (#42656795)

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!

Re:Come on! (1)

lengau (817416) | about 2 years ago | (#42657273)

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 feel like the security guard in Austin Powers... (5, Funny)

killfixx (148785) | about 2 years ago | (#42656807)

Standing before the steam roller....

"Stoooooooooooooooooooooooooooooooooooooooooooop".... .... "Stooooooooooooooooooooooooooooooooop"....

I understand, we need time to correct the issue, but...c'mon?!

Slow news day?

Not news (-1)

Anonymous Coward | about 2 years ago | (#42656827)

Shouldn't be news to anyone posting on this site. Jesus fuck, I wish all the fucktards and redditors would get the fuck off this site.

Re:Not news (-1)

Anonymous Coward | about 2 years ago | (#42656893)

+1

Re:Not news (-1)

Anonymous Coward | about 2 years ago | (#42656955)

Shouldn't be news to anyone posting on this site. Jesus fuck, I wish all the fucktards and redditors would get the fuck off this site.

You forgot hipsters.

The collective IQ of Slashdot has diminished over the past few years.

Unsigned! (3, Interesting)

aglider (2435074) | about 2 years ago | (#42656831)

32bit unsigned, not signed! What'd be the negative timestamps for? Ages before 1970?

Re:Unsigned! (0)

Anonymous Coward | about 2 years ago | (#42657031)

32bit unsigned, not signed! What'd be the negative timestamps for?
Ages before 1970?

Avast! The negative timestamps be for the forgotten yars way back when Jack Kennedy did found this great nation, even before that scurvy son of a bitch Nixon started the Civil War.

Re:Unsigned! (-1)

Anonymous Coward | about 2 years ago | (#42657037)

Are you fucking joking? It's up to the implementation to define this, anyway. And for the faggoty ass OS you people on here use, it's a signed integer you fag.

See my post above:
developers.slashdot.org/comments.pl?sid=3399939&cid=42656827

You prove my point. STOP POSTING.

Re:Unsigned! (2)

davydagger (2566757) | about 2 years ago | (#42657111)

"32bit unsigned, not signed!"
no you heard correct.

"What'd be the negative timestamps for? Ages before 1970?"

but you managed to guess this correctly.

Re:Unsigned! (2)

vlm (69642) | about 2 years ago | (#42657255)

Also a timestamp, in addition to being referenced to 0 = somesuch date, also can be used with offsets. So add a signed integer "-60" to the timestamp signed integer to get a signed integer representing about a minute ago. Since you'll be spending a lot of time adding signed ints to a timestamp, you may as well make the thing a signed int, rather than having to screw up and debug a zillion crappy bug filled homemade implementations of "uint + int = uint". Most of the bugs are dealing with extreme values and rollovers ... most of them.

On the bright side, at least they didn't use BCD or floats. floats would have been pretty funny, crontab entries not running because of rounding errors and stuff like that.

Re:Unsigned! (0)

Anonymous Coward | about 2 years ago | (#42657185)

error return. it's also easier to do arithmetic on signed numbers.

Re:Unsigned! (2)

Waffle Iron (339739) | about 2 years ago | (#42657235)

Do the math. If they used a 32-bit unsigned integer, the problem wouldn't happen until the year 2106.

Is it a real problem? (1)

ruir (2709173) | about 2 years ago | (#42656841)

As far as I am aware, only old Unix computers still use 32-bit time_t vars...

Re:Is it a real problem? (4, Insightful)

kenny603 (1754842) | about 2 years ago | (#42656923)

In terms of personal computers this isn't going to mean much probably by the time it happens. The problem is that there are many, many embedded devices out in the field that are still running with 32-bit time_t vars. Example from a previous job of mine: we made building automation controllers. Those are all devices that are still out in the field and they are all still running old code. Assuming the devices don't die before the time rollover or are not replaced with newer pieces of hardware then it might become a problem.

Re:Is it a real problem? (-1)

Anonymous Coward | about 2 years ago | (#42657207)

How many devices are you running from 1988 at the moment?

Re:Is it a real problem? (1)

Omegium (576650) | about 2 years ago | (#42657203)

Yes, the operating systems themselves will probably be fine by then. But what about programmers who had to do date calculations in a language without a good date object? They put dates in an int, and added 3600 for each hour. What about databases where timestamps are stored in plain ints, instead of a special time value? And then there are embedded systems of course, from microwaves to airplanes to networking equipment

Getting old (2)

boristdog (133725) | about 2 years ago | (#42656845)

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.

Re:Getting old (1)

Doug Otto (2821601) | about 2 years ago | (#42656989)

Amen Brother.

Re:Getting old (0)

Anonymous Coward | about 2 years ago | (#42657063)

I put my time working on the Y2K fix, going through hundreds of computers by hand that could not be automatized.

I won't be retired in 25 years, so I get to fix this one as well.

Hell, I hope I don't need the job in 25 years.

-j

Re:Getting old (2)

slim (1652) | about 2 years ago | (#42657231)

Yep. We knew Y2K was coming. We tested stuff. We fixed stuff. We got double-time for being on-call instead of partying like it's 1999. And because of all of that, it went smoothly.

The same thing will happen here. All it needs is for management to put people on the tasks.

Mortgage Calculations (5, Insightful)

bill_mcgonigle (4333) | about 2 years ago | (#42656855)

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.

Re:Mortgage Calculations (5, Funny)

Anonymous Coward | about 2 years ago | (#42657001)

Actually we did, but it had nothing to do with integer overflow.

Re:Mortgage Calculations (1)

Exitar (809068) | about 2 years ago | (#42657025)

The global crysis!
I blame UNIX for that!

Re:Mortgage Calculations (0)

Anonymous Coward | about 2 years ago | (#42657157)

I blame Crytek. :)

Re:Mortgage Calculations (1)

Anonymous Coward | about 2 years ago | (#42657035)

Oh really? There was no "earth-shattering kaboom" in the world of housing finance ~5 years ago?

Re:Mortgage Calculations (3, Funny)

Thud457 (234763) | about 2 years ago | (#42657081)

Mortgage systems using 32-bit time_t (if there ever were any) failed 5 years ago for 30-year mortgages.

Oh, that was what that was. Oh crap.
And here all along I've been blaming greedy mortgage brokers for suckering people into mortgages they couldn't afford and a insanely inflated real estate market.

Re:Mortgage Calculations (1)

plover (150551) | about 2 years ago | (#42657085)

Five years ago there was an economy-shattering real estate crash due to shady sub-prime mortgages. Coincidence or coverup?

Just kidding; of course it was a coincidence. But if you throw out statements like this, the conspiracy theorists come out of the woodwork. You could even say the moon landings were faked because the time on the computers of the day was kept in an 8-bit register, which rolled over during the Apollo 13 mission!

Re:Mortgage Calculations (0)

Anonymous Coward | about 2 years ago | (#42657263)

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.

There was supposed to be an earth shattering "kaboom"!

Re:Mortgage Calculations (1)

Waffle Iron (339739) | about 2 years ago | (#42657343)

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.

Maybe that's because accountant types seem to think that the only valid numerical inaccuracies are those manifested in base 10, so they tend to use their own weird decimal number types for financial calculations.

Re:Mortgage Calculations (0)

Anonymous Coward | about 2 years ago | (#42657417)

so that's what triggered the financial crisis ;)

Maybe (-1)

Anonymous Coward | about 2 years ago | (#42656865)

It'll finally get people to switch from Windows XP

fake!!!! Nothing to see here. (-1, Flamebait)

Anonymous Coward | about 2 years ago | (#42656901)

Unix time has been 64 bits for a long time now.

This article was written by a {loser} windows 8 person.
Nothing to see here.

Oh No! (1)

MyLongNickName (822545) | about 2 years ago | (#42656921)

This could be worse than Y2K!

Re:Oh No! (1)

tippe (1136385) | about 2 years ago | (#42657169)

It's time (haha) to pull those windows and mainframe programmers that saved us from Y2K out of retirement. They'll know what to do...

Re:Oh No! (1)

PolygamousRanchKid (1290638) | about 2 years ago | (#42657223)

This could be worse than Y2K!

. . . and more lucrative, for retired C hackers who want to earn a few bucks . . .

The COBOL boys had their turn with Y2K. Next up, are the C-bies.

Just use Dice(r) Job Boards! (1)

larry bagina (561269) | about 2 years ago | (#42656959)

Dice (r) is the best place to find programmers to fix your Y2k38 problems.

Re:Just use Dice(r) Job Boards! (0)

Anonymous Coward | about 2 years ago | (#42657123)

This post was removed due to Dice content standards violations.

Noooooooo! (5, Funny)

lxs (131946) | about 2 years ago | (#42656971)

My uptime!

Surely we'll all be using 64bit by then. (2, Funny)

Arancaytar (966377) | about 2 years ago | (#42656975)

After all, we handily averted Y2K with decades to spare, and the internet has been migrated to IPv6 for the past ten years. :-P

Re:Surely we'll all be using 64bit by then. (1)

rossdee (243626) | about 2 years ago | (#42657139)

And the Mayan clock rollover didn't seem to cause any problems.

WP article much better (1)

bcrowell (177657) | about 2 years ago | (#42656979)

The Wikipedia article [wikipedia.org] 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.

Re:WP article much better (2)

ledow (319597) | about 2 years ago | (#42657115)

Why can't you do that with an airliner? Maybe a car, but a car that's still running in 25 years is quite an achievement anyway.

On an airliner? Just basic operational procedure would mean that updates for fixes are common (physical or software) to fix ANY potential problem after YEARS of testing on identical systems deployed in test labs.

There's almost certainly a copy of a Boeing's internals at Boeing where they've done exactly this (e.g. test Y2K rollover to make sure it doesn't affect flightplan or autopilot) and they didn't risk a plane to do so.

25 years means none of your current desktops will still be running (it would be like running a ZX Spectrum as a business machine would be seen today). There might be embedded devices, but how many will go 25 years without a SINGLE test or upgrade or fix or replacement? Very, very, very few.

There isn't a network switch in the world deployed today that will still be around in 25 years untouched. It would literally be like finding out a ZX Spectrum was running vital parts of your business by being tucked away in a cupboard and forgotten about for 25 years and NOT ONE PERSON KNOWING.

Re:WP article much better (2)

LDAPMAN (930041) | about 2 years ago | (#42657339)

I've actually seen some situations close to your example. Imagine 286 desktop machines running Netware 2.X for SAA. It was at a hospital and the only guy that knew anything about them had been dead for almost 6 years. Finally enough of them failed to impact connectivity to the mainframe.

Re:WP article much better (1)

vlm (69642) | about 2 years ago | (#42657415)

They're probably talking about endless dependency stream style bugs.

For example. Say your shitty GPS rx curls up and dies with the 32 bit roll over. So it either stops sending fixes to the moving map or the moving map decides not to accept post-32-bit timestamps as part of the NMEA stream. Either way the position becomes static so the calculate airspeed drops to zero. Normally it would cross check against the two tubes, but those are clogged by ice today. So the autopilot shoves the stick far over because the planes in a stall and floors the engine.

Assuming the plane doesn't crash (and it probably won't... this is hardly the first time in aviation history that an autopilot broke) will get the trouble ticket for a broken autopilot, then has to work backward to figure out the moving map is broke, move back to find the GPS is broke...

Even funnier would be really shitty arithmetic implementations. Like a "one" value in bit 32 is somehow, accidentally the MSB/LSB/something now added to the lat/lon. Again pissing off the autopilot into thinking you're now suddenly 15000 miles off course and need to enter a gentle turn to the north to correct. The odds of that being unnoticed and there being a mountain there are actually pretty low, but its still going to be an unholy PITA to investigate and "solve".

Or overzealous security monster type paranoid "24 tv show fan" type firewall type design.. Why, the date "has" to be pre-32 bit, right? So filter anything "wrong" out. Whoops that makes the engine computer crash. Well thats annoying. Or the GPS isn't broken at all, but the moving map display interpretation code actually is broken. Overall just as annoying as hell.

Re:WP article much better (1)

Annirak (181684) | about 2 years ago | (#42657187)

(Do people still read Byte? I don't remember seeing it since the 80's.)

Only in strings. We migrated to Words in the late '80s, then DWords in the '90s.

Re:WP article much better (0)

Anonymous Coward | about 2 years ago | (#42657239)

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.

Y2K was massively about embedded systems and few of the real problems were with desktops.

Re:WP article much better (1)

davydagger (2566757) | about 2 years ago | (#42657387)

given that most new UNIX systems are now 64 bit to include new ARM machines, I don't see a scenario in 25 years where we will be using anything that requires the date to work.

will most embedded systems need the date to work as an absolute, ot just need to count seconds? Why does an industrial robot care if its 2038 or 1901?

Since When Do Politicians Use Unix? (1)

xxxJonBoyxxx (565205) | about 2 years ago | (#42656985)

>> 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 (3, Funny)

Dyinobal (1427207) | about 2 years ago | (#42656993)

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?

Re:Time overflowing (2)

ChocNut (791621) | about 2 years ago | (#42657097)

Look up John Titor.

I'll be 70 or dead (1)

swb (14022) | about 2 years ago | (#42657017)

So it will be someone else's problem.

that give time for there to be a PHD level class (0)

Anonymous Coward | about 2 years ago | (#42657019)

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

Re:that give time for there to be a PHD level clas (1)

vlm (69642) | about 2 years ago | (#42657445)

and your loans will be like 500K

Per textbook

Well (2)

ledow (319597) | about 2 years ago | (#42657039)

"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.

Re:Well (1)

gweihir (88907) | about 2 years ago | (#42657277)

I expect that financial calculations are using 64 bit or 128 bit integers, long-numbers or at the very least (may be illegal in some countries) double. The last still gives 56 bit integer precision when misused as an integer.

Another Global Warming Scare (1)

mtrachtenberg (67780) | about 2 years ago | (#42657055)

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.

By then... (0)

Alien Being (18488) | about 2 years ago | (#42657067)

I'll be almost 2.5 gigaseconds old and won't give one nanoshit.

I will be collecting Social Security by that time (0)

Anonymous Coward | about 2 years ago | (#42657069)

So whoever is going to fix it, I don't want my check to be late.

Now get off my future lawn.

safe on 64bit Linux (0)

Anonymous Coward | about 2 years ago | (#42657089)

no comment

They got one thing right. (0)

Anonymous Coward | about 2 years ago | (#42657109)

At least none will be able to say slashdot was late with this report.

32-bit signed integer? (0)

Anonymous Coward | about 2 years ago | (#42657125)

Why would they use a signed integer for something that started at zero and cannot be negative?

Simple fix (1)

Registered Coward v2 (447531) | about 2 years ago | (#42657151)

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

When Do /. UIDs Overflow? (1)

RedHackTea (2779623) | about 2 years ago | (#42657189)

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.

typedef int64_t time_t; (1)

Rob Riggs (6418) | about 2 years ago | (#42657261)

There -- it's fixed.

PHP (0)

Anonymous Coward | about 2 years ago | (#42657287)

PHP is still screwed, no 64-bit integers.

Re:PHP (0)

Anonymous Coward | about 2 years ago | (#42657405)

PHP is already screwed. Why? It exists. Can't get any worse than that.

Shhhhh!! (3, Interesting)

hawguy (1600213) | about 2 years ago | (#42657293)

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.

VMS never had this problem (1)

VAXcat (674775) | about 2 years ago | (#42657303)

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.

No lets panic (1)

cod3r_ (2031620) | about 2 years ago | (#42657367)

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.

John Titor (0)

Anonymous Coward | about 2 years ago | (#42657395)

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...

Y2K hysteria alloevr again... (0)

Anonymous Coward | about 2 years ago | (#42657397)

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.

A real problem! (1)

Murdoch5 (1563847) | about 2 years ago | (#42657425)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?