Dinjiin: Meh. I'd worry about the Y2038 issue first.Unlike the Y2K bug, which was mostly hype and only affected a handful of poorly written programs, the Y2038 issue could have some potential for impact. Anything which uses the time_t, which is the recommended method of keeping track of time in programs, will fail on systems where it maps to a signed 32-bit integer. So even properly developed software, including operating systems, will fail.There is a lot of software from the 60s-90s still running on modern mainframes and servers within virtual machines (VMs) that will need to be reprogrammed, notably a lot of old stuff programmed in COBOL for the finance and banking sector.Most mainframes and UNIX systems have switched to using signed 64-bit integers to store time_t, which is what the article is joking about in a tongue-and-cheek way. So yeah, we're good for another 293 billion years if you're using that in your software.In a decade or two, even that might be pushed out. It is a matter of time before processors used in mainframes, servers and workstations switch from using a 64-bit integer as their native data type to either 128-bit or even 256-bit. It is usually faster and easier to manipulate a value stored as the native data type than something smaller, so time_t might get bumped in size again. Some people propose that when we get to that point, we might switch from the number of seconds since 1901 to the number of milliseconds since 1901./you can read about more time bugs here//the mid-2030s will be a boom time for COBOL programmers
Dinjiin: //the mid-2030s will be a boom time for COBOL programmers
Links are submitted by members of the Fark community.
When community members submit a link, they also write a custom headline for the story.
Other Farkers comment on the links. This is the number of comments. Click here to read them.
You need to create an account to submit links or post comments.
Click here to submit a link.
Also on Fark
Submit a Link »
Copyright © 1999 - 2017 Fark, Inc | Last updated: Jul 28 2017 16:15:01
Runtime: 0.160 sec (160 ms)