UNIX time just rolled over

[Dog Cow]

I just noticed this, it used to be that UNIX times were 1199982205 and such, but it looks like we have just rolled over to 1200003757 and so on.

How long does that take to go from 119 to 120?

[drathbun]

Figure out how many seconds it is. There is another Y2K issue coming in 2035 (I think that's the year) when unix timestamps will roll from 999...999 over to an overflow condition. Better start preparing now...

[A_Jelly_Doughnut]

That would be 100,000,000 (100 million) seconds, or roughly 3.16 years.

I don't know of any reason why it would be difficult to add another byte to the unix timestamp paradigm (from 11 to 12 integers). That would extend the life of timestamps by just shy of one trillion seconds ... or 31,000 years.

EDIT: Oh yeah...32 bit integer limit. *slaps A_Jelly_Doughnut*

[Paul]

Figure out how many seconds it is. There is another Y2K issue coming in 2035 (I think that's the year) when unix timestamps will roll from 999...999 over to an overflow condition. Better start preparing now...

You mean at Tue Jan 19 04:14:07 2038

[Jim_UK]

You mean at Tue Jan 19 04:14:07 2038

As I will be 90 then I shall put worry about that on the back burner.

Jim

[Nicholas the Italian]

Figure out how many seconds it is. There is another Y2K issue coming in 2035 (I think that's the year) when unix timestamps will roll from 999...999 over to an overflow condition. Better start preparing now...

You mean at Tue Jan 19 04:14:07 2038

To be more precise, it has nothing to do with "9999...99": it will roll from 2,147,483,647 to 2,147,483,648, that, in binary notation, means from 0111,1111,1111,1111,1111,1111,1111,1111 to 1000,0000,0000,0000,0000,0000,0000,0000; the latter, considered as a SIGNED 32-bit long number, will be -2,147,483,648 [minus!], that is Fri, 13 Dec 1901 20:45:52 GMT.
Now, if programmers will be intelligent enough to consider timestamps as UNSIGNED numbers, then any number up to 4,294,967,295 will be good, and that will move the "billennium bug" forward to year 2106.

*edit*
http://en.wikipedia.org/wiki/Year_2038_problem

[Dog Cow]

I have to admit that it'll take me a bit to get used to the 120xxxx, instead of 119. When I first saw it, I thought it was a glitch!

[drathbun]

To be more precise, it has nothing to do with "9999...99": it will roll from 2,147,483,647 to 2,147,483,648, that, in binary notation, means from 0111,1111,1111,1111,1111,1111,1111,1111 to 1000,0000,0000,0000,0000,0000,0000,0000; the latter, considered as a SIGNED 32-bit long number, will be -2,147,483,648 [minus!], that is Fri, 13 Dec 1901 20:45:52 GMT.
Now, if programmers will be intelligent enough to consider timestamps as UNSIGNED numbers, then any number up to 4,294,967,295 will be good, and that will move the "billennium bug" forward to year 2106.

*edit*
http://en.wikipedia.org/wiki/Year_2038_problem

Perfect, that was exactly what I had in mind. Thanks for the wiki link.

[The Awesomest Dude]

I had also wondered about that. I never did any research on it, or even thought about when the year would be. (I do appreciate this information!) Yes this is somthing that everybody (myself included) should start thinking about if they are not already.

Just remember that in the 70's and early 80's, everybody assumed that nobody would still be using the same computers, equipment, and software that were presently being used. So they didn't see anything wrong with having it stop at '99.

2038 is 30 years from now. 30 years is not very far away.

It's just something to think about. It's no immediate threat but it is something that will be a problem down the road if not fixed. Just something to think about.

Just my 2 cents worth.

[Nicholas the Italian]

Firstly, 64-bit systems are starting to pop up, so I guess that in 10 years or so basically every computer will be 64-bit, with timestamps redefined as 64-bit long.

Secondly (and especially for, say, embedded devices, which might still be 32 bit), if we suppose that dates before 1970 are irrelevant (as it's probably the case for embedded devices), there's really nothing to change about timestamps, except that when you read them you have to consider them as unsigned 32-bit numbers. As said above this would move the issue to 2106, and would not cause backward compatibily problems or anything (so, it should be easier than changing every piece of program to use YYYY instead of YY, like in the Y2K bug).

Thirdly, we could define a new "timestamp" (eg. "Y2K timestamp", going from 1st January 2000 to year 2136) and use it in new systems in place of (or in addition of) unix timestamps. Some conversion work required for data, but nothing impossible.

Fourthly, people are discussing the 2038 problem 30 years earlier, while the Y2K bug was widely discussed when, in 1998? (And was not that much of a problem, in the end.)

So, I don't think it will really be a big issue.

What about this...

As I will be 90 then I shall put worry about that on the back burner.

Yes, but what if you die in 2050 and get on your tombstone:

Code: Select all

Jim_UK
1948-1913

[Dog Cow]

You know, all of this date stuff wouldn't be a problem if we just went to using Roman Numerals like in motion picture copyrights.....

[Nicholas the Italian]

You know, all of this date stuff wouldn't be a problem if we just went to using Roman Numerals like in motion picture copyrights.....

Code: Select all

Today is XVI I MMVIII.
We entered year MM just I second after XXXI XII MCMXCIX, XXIII:LIX:LIX.

Yeah it works, just save it as VARCHAR and you're done with it.

PS: still, this would move the issue to year 4000, as there's no easy way of writing 4000 in roman.

[The Awesomest Dude]

Firstly, 64-bit systems are starting to pop up, so I guess that in 10 years or so basically every computer will be 64-bit, with timestamps redefined as 64-bit long.

Yes, but what about those who never upgrade? And you might be surprised how many people don't. I am constantly amazed at how many people think that everybody upgrades hardware, software, etc., on a regular basis. And I am talking about very intelligent people, who know alot about so many different things... but are incorrect about that one little thing... (And I don't know why that mistake is so common. Does anybody know?)

But yes, contrary to popular belief, MOST people DO NOT upgrade every time, every year, or even every few years. There are many, many people who still use computers from the mid-90's.

Mine is brand new but that's because my other one crashed. It was about 3 years old. It had XP like I wish this one had. (If I had known how bad Vista was I would have bought a used one, but that's a different discussion for a different time...) Before I got that one, I was using one that was probably about 5 or 6 years old at that time. Of course my main point was that there are people who use computers that are even older than that!

So yes, please do keep that in mind. In 2038 there might very well be people who still use the same exact equipment that is in use right now.

Secondly (and especially for, say, embedded devices, which might still be 32 bit), if we suppose that dates before 1970 are irrelevant (as it's probably the case for embedded devices), there's really nothing to change about timestamps, except that when you read them you have to consider them as unsigned 32-bit numbers. As said above this would move the issue to 2106, and would not cause backward compatibily problems or anything (so, it should be easier than changing every piece of program to use YYYY instead of YY, like in the Y2K bug).

That's true. And 30 years should be enough time to do all that.

Thirdly, we could define a new "timestamp" (eg. "Y2K timestamp", going from 1st January 2000 to year 2136) and use it in new systems in place of (or in addition of) unix timestamps. Some conversion work required for data, but nothing impossible.

That's a good idea, but yes, some conversion work.

It could happen though. That's a good idea.

Fourthly, people are discussing the 2038 problem 30 years earlier, while the Y2K bug was widely discussed when, in 1998? (And was not that much of a problem, in the end.)

Well, about '96 or '97, but yes you are correct. If they had planned ahead that wouldn't have happened.

But if you noticed, a computer purchased around that time still only went up to 2099. And much of my digital equipment (such as my camera, for example) only goes up to like 2080. So perhaps they didn't learn very much from it?

What about this...

LOL

Now that, you are very correct about. Anything that is over 200 years away (preferably 300+), is not a serious problem, IMO. (I'll elaborate on this if asked...)

[Nicholas the Italian]

But yes, contrary to popular belief, MOST people DO NOT upgrade every time, every year, or even every few years. There are many, many people who still use computers from the mid-90's.

I'm perfectly aware of this. I was using a Pentium 75Mhz with 8MB RAM when Win XP came out. Age of Empires I wouldn't run smoothly.
Anyway, organizations are somewhat forced to a certain turn-over in everything. We may not agree whether that's on 5-year, 7-year or 10-year basis, but as far as computer goes, I highly doubt that anything can survive longer than 10-15 years (as things are now).
So while I perfectly accept that Win XP (released in 2001) might still be in use by many people in 2015, I doubt we will see it around in 2020. And I don't think that today systems (either hardware or software) will be in use 20 years from now.
At least, I hope that critical organisation (banks, enterprises, PA, etc.) will have moved on at that time.
Still, this may be problem for look-ahead applications (eg, if something expires 30 years from now, it's going to expire in 1901 according to unix timestamp). Though I guess few practical applications go as far as calculating timestamps more than 10 years in the future.
Anyway, if we consider a 10-year look-ahead, a 10-year turn-over time, and a 5-year margin, this is about the right time to think about the issue.

Things change a bit for embedded devices, which can be put quite everywhere and left working for years, even a decade (or more, presumably, in the future).
Not sure what problems in embedded devices would lead to. As long as we talk about microwaves or cell phones or ID cards, I wouldn't mind. But in the future EDs might be used in more critical situations.

Bottom line, we survived Y2K bug (working one year and spending billions of dollars - btw, nations who didn't spend a cent got away with it just like nations who spent a lot ), I don't see why this problem should be any worse.

[The Awesomest Dude]

Hopefully you are correct. You probably are correct but I guess only time will tell.

At the very worst, we've got 30 years to prepare for it. So I think everything will be ok. (I hope so anyway, LOL)