If you can read this, either the style sheet didn't load or you have an older browser that doesn't support style sheets. Try clearing your browser cache and refreshing the page.

(Gizmodo)   The Mayan Apocalypse was obviously stupid, but this is the exact date when our computer world ends. For real   (gizmodo.com) divider line 31
    More: Interesting, Chandra X-ray Observatory, Michio Kaku, interstellar travel, galaxy clusters, civilizations, integers, Unix, red giants  
•       •       •

8946 clicks; posted to Geek » on 27 Dec 2012 at 2:14 PM (1 year ago)   |  Favorite    |   share:  Share on Twitter share via Email Share on Facebook   more»



31 Comments   (+0 »)
   
View Voting Results: Smartest and Funniest

Archived thread
 
2012-12-27 01:09:30 PM
www.lolbrary.com
 
2012-12-27 01:14:22 PM
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
 
2012-12-27 01:28:40 PM
EVERYBODY PANIC!

/wait... the hell?
 
ZAZ [TotalFark]
2012-12-27 02:05:08 PM
What does Windows use as a time base? That's the counter I worry about.
 
2012-12-27 02:18:19 PM
If we survive that long Subby, we no longer will be using physical computers. Or be human.
 
2012-12-27 02:20:15 PM

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


There was once a COBOL programmer who was getting burned out with all the Y2K
conversions taking place. He was so stressed out that he finally arranged to
have himself put in cryostasis until after Jan 1, 2000.

Time passed and he awoke to find himself in a white room with lots of people
rushing around. A voice from behind his head spoke in an awed whisper, "He's
awake!" Activity in the room stopped as all turned to look at him. He was a
bit nervous and asked if everything had gone ok - was he in good health and so
on. A nurse assured him he was ok, the doctors declared all his tests showed
him to be in excellent health. He was given a sumpious meal and all his wishes
were immediately fulfilled.

While all this attention pleased him it also made him a bit nervous. He kept
asking what day it was and he was told to never mind that all was well.
Finally about a week after he awakened a very official man walked into the room
and sat in the chair near his bed. He told the programmer that the Galaxy
Leader wanted to speak with him. A screen came down from the ceiling and a man
appeared who had a eerie resemblence to Bill Gates, he spoke....

"I have some bad news for you. You were scheduled to be awakened on 8/1/2000
but there was a glitch in the programming and it is now 8/1/9999. You have
nothing to worry about, all disease and war have been eliminated and the world
lives in peace and harmony. We hope to continue to live this way, but to do so
we need your help....

We understand you know COBOL......"
 
2012-12-27 02:21:51 PM

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


non-issue. All that shiat will be gone by then
 
2012-12-27 02:25:14 PM

Dinjiin: //the mid-2030s will be a boom time for COBOL programmers


Oh great, a bunch of COBOL programmers rising from their graves....
 
2012-12-27 02:43:12 PM
If we are still using Linux 292 billion years for now, we have bigger problems.
 
2012-12-27 02:45:50 PM
But no one wants to live that long anyways...
 
2012-12-27 02:50:13 PM

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.


It gets even more fun when you think about embedded. How many people actually patch their router firmware regularly? Then again, your home router thinking it's 1970 probably won't hurt anything anyway.
 
2012-12-27 02:52:31 PM
I'm a freshman in College, and I'm really considering learning COBOL.
 
2012-12-27 02:55:23 PM

ProfessorOhki: Then again, your home router thinking it's 1970 probably won't hurt anything anyway.


Certain encryption standards require dates to be set correctly. This includes the home router. If the date on your machine is 2038 and the date on your router is 1970, it won't like it.
 
2012-12-27 02:56:52 PM

Rockstone: ProfessorOhki: Then again, your home router thinking it's 1970 probably won't hurt anything anyway.

Certain encryption standards require dates to be set correctly. This includes the home router. If the date on your machine is 2038 and the date on your router is 1970, it won't like it.


Hmm, good point.
 
2012-12-27 02:58:55 PM
ProfessorOhki: Then again, your home router thinking it's 1970 probably won't hurt anything anyway.

Will it make all my porn bushy?
 
2012-12-27 04:26:52 PM

Quantum Apostrophe: But no one wants to live that long anyways...


Just find the last Highlander and take his head already.
 
2012-12-27 05:09:49 PM
Another worthless "article" from the most worthless author on that worthless site.

Nice going, subby.
 
2012-12-27 05:21:55 PM
www.terrilynnesmiles.com

Had enough of the Real World, wants back in to the Computer World.
 
2012-12-27 05:32:30 PM

Rockstone: ProfessorOhki: Then again, your home router thinking it's 1970 probably won't hurt anything anyway.

Certain encryption standards require dates to be set correctly. This includes the home router. If the date on your machine is 2038 and the date on your router is 1970, it won't like it.


A surpring number of home routers and cable modems run either Linux, VxWorks (BSD) or QNX, so they may actually be fine since they use something larger than a signed 32 bit integer to hold time.

Besides, I think most wireless devices will be made obsolete due to exploits or increasing weaknesses in their encryption, or just from being slow and outdated before any issues with time become a problem.

And as for other embedded devices, it just comes down to programming. Because even 8 bit processors like the old 6502 can do 64 bit math. They're just slow at it since they have to work in 8 biatchunks.
 
2012-12-27 05:50:53 PM
Dinjiin: And as for other embedded devices, it just comes down to programming. Because even 8 bit processors like the old 6502 can do 64 bit math. They're just slow at it since they have to work in 8 biatchunks.

I love the filter.
 
2012-12-27 06:12:36 PM

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.


The Y2K bug was NOT a lot of hype. It was just well-managed, surprisingly. And caught early enough to fix for.

The Y2038 bug will be naturally fixed as integers grow to 64-bits.
 
2012-12-27 06:19:32 PM

Dinjiin: Rockstone: ProfessorOhki: Then again, your home router thinking it's 1970 probably won't hurt anything anyway.

Certain encryption standards require dates to be set correctly. This includes the home router. If the date on your machine is 2038 and the date on your router is 1970, it won't like it.

A surpring number of home routers and cable modems run either Linux, VxWorks (BSD) or QNX, so they may actually be fine since they use something larger than a signed 32 bit integer to hold time.

Besides, I think most wireless devices will be made obsolete due to exploits or increasing weaknesses in their encryption, or just from being slow and outdated before any issues with time become a problem.

And as for other embedded devices, it just comes down to programming. Because even 8 bit processors like the old 6502 can do 64 bit math. They're just slow at it since they have to work in 8 biatchunks.


Didn't know at what point time_t became 64 rather than 32. I know some older stuff just typedef's it to a long. Working with 64 bit time on a 16 bit uC as we speak :)
 
2012-12-27 06:24:24 PM

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

The Y2K bug was NOT a lot of hype. It was just well-managed, surprisingly. And caught early enough to fix for.

The Y2038 bug will be naturally fixed as integers grow to 64-bits.


I had many long nights in '97 and '98 that attest to there having been an actual problem that industry managed to take seriously, for a change.

It was nice that the first things to be affected were long-horizon dates. E.g. when credit cards started failing because they looked like they had expired in 1900, there was still plenty of time to reissue cards that expired in 1999 instead, and then fix the code before dates in 2000 became necessary, rather than merely convenient. But since there were failures, it was easier to convince Management that the massive effort was really needed.

I remember a few systems that were fixed to use a 4-digit date before they were fixed to display a 4-digit date, so you had ugly things like "year of graduation" showing up as either 19 or 20 for a while. But because the underlying data had been corrected, it was only a cosmetic issue.
 
2012-12-27 06:43:45 PM

ArcadianRefugee: Another worthless "article" from the most worthless author on that worthless site.

Nice going, subby.


Hey! Jesus (Diaz) said this, so you must listen!

/Actually think it a mildly interesting topic, but JESUS Gizmodo!
 
2012-12-27 07:01:19 PM
Cerebral Knievel: Just find the last Highlander and take his head already.

In spaaaaaaaace!!!!
 
2012-12-27 07:04:30 PM

blue_2501: The Y2K bug was NOT a lot of hype.


There was a lot of talk from the media that mission critical systems such as power grids and control systems would fail.  Lots of doom and gloom. The overpriced consultants I used to work with who did Y2K remediation said it was mostly cheap HR systems and very old mainframe finance applications that most commonly had the bug.  Programs were either truncating the dates at input or when they were saved into a table in a database.

From the anecdotal evidence I've heard, it sounds as if it could have been a costly issue, but not really a dangerous one. And companies who were at risk of financial apocalypse were well funded enough to correct the issue in advance.
 
2012-12-27 08:41:35 PM
//the mid-2030s will be a boom time for COBOL programmers

yay, i'll only be in my 80s then
 
2012-12-28 06:45:04 AM

ZAZ: What does Windows use as a time base? That's the counter I worry about.


time_t

Is your OS 64 bit?

/Will your OS in 2038 be at least 64 bit?
 
ZAZ [TotalFark]
2012-12-28 12:02:35 PM
Benni K Rok

And what is a Windows time_t?

Windows whatever-they-call-it-these-days is based on Windows NT which is based on VMS which does not count seconds, but tenths of microseconds. According to Wikipedia the VMS time counter expires at 31-JUL-31086 02:48:05.47.
 
2012-12-28 03:23:11 PM

E_Henry_Thripshaws_Disease: //the mid-2030s will be a boom time for COBOL programmers

yay, i'll only be in my 80s then


I'll be in my mid/late 30s/early 40s then.

Better learn COBOL now.
 
2012-12-28 04:34:34 PM

ZAZ: Benni K Rok

And what is a Windows time_t?

Windows whatever-they-call-it-these-days is based on Windows NT which is based on VMS which does not count seconds, but tenths of microseconds. According to Wikipedia the VMS time counter expires at 31-JUL-31086 02:48:05.47.


Meh? time_t is a C library standard, though it can be 32 or 64 bit, referenced from the Unix epoch. Starting at least with VC++ 2005, time_t is 64 bit, though a coder can override that at compile time. Sure NT shares some VMS genes, but I'm not aware that VMS-style time functions exist in user APIs. There are a wealth of time functions available with higher resolution than that of time(), but unless your app is doing something special, it is wise to use time()
 
Displayed 31 of 31 comments

View Voting Results: Smartest and Funniest


This thread is archived, and closed to new comments.

Continue Farking
Submit a Link »






Report