Y2K38 Watch Starts Saturday

Jon Masters writes "I just wanted to remind everyone that Saturday, January 19th 2008 will mark the beginning of the 30-year countdown to the Y2K38 bug, when Unix time will overflow 32 bits. Some 30-year loan calculation software might start having problems with this over the weekend."

Comments

And other things..

[suso]

I think Boeing or some aircraft company was one of the first company to run into Y2K problems because of how they plan their building schedule or something. So they might encounter Y2K38 problems.

I always found it interesting that 1 billion seconds happened 2 days before 9/11. It never seemed to be mentioned much. I'm not trying to make conspiracy theories, but its probably one few times that an apocalyptic-like event happened so close to a man made time scale.

Re:And other things..

[Malevolent Tester]

Apocalyptic event? Last time I checked, the world was still here. Epochal, perhaps, as I suspect it will be the defining event for my generation, much like the moon landing or JFK forgetting to duck, but in the grand scheme of things it was no more apocalyptic than the 2005 tsunami.

Re:And other things..

[merreborn]

I always found it interesting that 1 billion seconds happened 2 days before 9/11.

You can come up with any number of numerological associations for any event. Seriously. Try it some time. Pick any event, and you can come up with a dozen, if you try.

Re:And other things..

[moderatorrater]

Yeah, kind of like how Christ was born so close to the changeover from BC to AD.

Re:And other things..

[Anonymous Coward]

I think your scales are off. The 2004 tsunami was a massive loss of life (225,000 people in eleven countries) compared to the 2,999 people killed in the airplane attack of 9/11/01.

I was a little appalled at the lack of coverage and donations given to the victims of the tsunami compared to the massive outpouring given to the 9/11 victims. It must just be that fact that I am in America now, and the media / government is so stuck on only looking inside the country and not what happens in other countries (unless it involves oil).

I am also continually amazed at how the governments of the world (mainly US and UK, but others too) are using the two events (9/11 and 7/7) to push all of these "security" measures. As a child growing up during the IRA bombings, I find it easy to compare the IRA to al-Qaeda, but the reactions of the governments are way out of proportion. Never did anyone think that a national ID should be implemented, and the background checks now-a-days are beyond what is needed.

If 9/11 defines that generation, then I'm so happy to be an old fart. I never would let a terrorist act define me.

Re:And other things..

[Bob-taro]

You can come up with any number of numerological associations for any event. Seriously. Try it some time. Pick any event, and you can come up with a dozen, if you try.

Really?! So there are always at least 12 numerological associations with every event in history?! OMG, I'm totally freaking out!!!11!1!

Re:And other things..

[cheeseboy001]

... its probably one few times that an apocalyptic-like event happened so close to a man made time scale.

So close? It was 172800 seconds off!

Re:And other things..

[Cajun Hell]

You can come up with any number of numerological associations for any event. Seriously. Try it some time. Pick any event, and you can come up with a dozen, if you try.

Interesting that of all the numbers you could have mentioned, you just happened to pick dozen: the number of eggs that are most often sold together. This suggests you are a chicken farmer. Your uid is another clue: 853723. 8+5+3+7+2+3=28. 28 % 12 = 4, which happens to be your comment's score at the time I type this. 853723 %12 = 7. You bring your eggs to market every week.

Look at all I have learned about you. And you think numerology doesn't work.

Re:And other things..

[Skreems]

Ah, but 172800 seconds is significant. 1+7+2+8+0+0 = 18, which is (9*1)+(9*1), which is 9(1+1). 9/11!

Re:And other things..

[pak9rabid]

Yeah, kind of like how Christ was born so close to the changeover from BC to AD. Heh, or how Christmas just 'happens' to be so close to the winter solstice ?

Re:And other things..

[Anonymous Coward]

Yeah,

Only 4 B.C. at the latest since the accounts say he was borne in the reign of Herod!

Re:And other things..

[Anonymous Coward]

Not to mention the fact that Christ was born on Christmas day. Talk about a coincidence!

(Yes, I know even biblical scholars don't think he was born anywhere near Christmas, so pedants can rest easy.)

Re:And other things..

[GNUALMAFUERTE]

You talk as if jesus existed. That would be bad, because since God doesn't exist, that turns him into a Bastard.

Re:And other things..

[Dark$ide]

I always found it interesting that 1 billion seconds happened 2 days before 9/11. Is that 10^12 (a billion) or 10^9 (an American billion or what I'd call one thousand million)?

Re:And other things..

[hansamurai]

Lack of coverage and donations? I would agree that at least coverage wise, the tsunami did not grab the nation the same way 9/11 did, but looking at the money donated is another story.

First I would encourage you to look at this:
http://en.wikipedia.org/wiki/Humanitarian_response_to_the_2004_Indian_Ocean_earthquake#List_of_Donors

The United States government donated nearly one billion dollars and another 1.9 billion came from its citizens and NGOs. That's nearly 3 billion dollars total. A total of 10 billion dollars was given to relief from around the world.

Granted, that comes to around 0.0026% of our GDP (someone correct me if I'm reading that wrong, permilles aren't my strong suit), but it's still a massive out pouring of money if you ask me.

Re:And other things..

[ehrichweiss]

Yep. Just look at the number 23 and the Law of Fives.

Re:And other things..

[Anonymous Coward]

Going way off topic here: You mentioned IRA. I wonder how the IRA or a group like ETA stack up against al Qaeda in terms of death counts and such.

Bad as they were, they never seemed to inspire the same kind of hysteria that Bin Ladens band of merry Muslims have.

Is it just the economic and political interests involved, or is the world is just more hysterical now a days.

Re:And other things..

[COMON$]

_Insert end of the world Family Guy joke here._

Re:And other things..

[Anonymous Coward]

pedants can rest easy

What website do you think you're on?!

Re:And other things..

[Anonymous Coward]

"I was a little appalled at the lack of coverage and donations given to the victims of the tsunami compared to the massive outpouring given to the 9/11 victims. It must just be that fact that I am in America now, and the media / government is so stuck on only looking inside the country and not what happens in other countries (unless it involves oil)."

Excuse me... but if my memory holds true.. the United States was the biggest contributor to AID after the tsunami. I can also say that the United States most of the time is the first to respond to most world wide disasters.

Re:And other things..

[halber_mensch]

You can come up with any number of numerological associations for any event. Seriously. Try it some time. Pick any event, and you can come up with a dozen, if you try.

Interesting that of all the numbers you could have mentioned, you just happened to pick dozen: the number of eggs that are most often sold together. This suggests you are a chicken farmer. Your uid is another clue: 853723. 8+5+3+7+2+3=28. 28 % 12 = 4, which happens to be your comment's score at the time I type this. 853723 %12 = 7. You bring your eggs to market every week.

Look at all I have learned about you. And you think numerology doesn't work.

You forgot the most obvious - 853723: 8 + 5 + 3 + 7 = 23. This chicken farmer has a name: Topsy Kretts. Watch out!

Re:And other things..

[Anonymous Coward]

I think it's race. Brown people are more scary. Nobody's scared of right wing wackos, like Timothy McVeigh, because they are white, right?

Re:And other things..

[ddoctor]

Lack of donations?
From memory, Australia gave a billion dollars to the tsunami relief.

I remember a snippet from a current affair show saying basically that al-Qaeda is more of a shared brand name, than an organisation.

11/9 was just big because it was in the US. Anti-US sentiment aside, the US is simply a more influential country than any of those affected by the Tsunami. US has very a powerful media and politic, so of course its going to be well covered.

I wouldn't like 11/9 to define my generation... I'd prefer something more positive... like, maybe something like the World Wide Web. Invented in 1989 (I was 8, so that's gotta be "my generation"), the web has been, by far, the greatest development which has happened in my generation. Sure, I'm a nerd (where am I again), but perspective, please.

Deaths and wars aside, the worst part of 11/9 was the bloody back-to-front dates!

Re:And other things..

[Surt]

Some links for the interested:

http://en.wikipedia.org/wiki/Humanitarian_response_to_the_2004_Indian_Ocean_earthquake

http://en.wikipedia.org/wiki/Financial_assistance_following_the_September_11%2C_2001_attacks

The bottom line seems to be that the government response to 9/11 was substantially larger (to compensate the victim's families, who were very high earners, and which was essentially necessary to rescue the airline insurance industry from lawsuits). Whereas the public outpouring of donations to victims was quite a bit larger for the tsunami.

Re:And other things..

[DetJohnKimball]

You are right that a National ID card in the UK was not considered. However, what was considered was an Irish ID Card. It was desired that all Irish in the UK had to show ID and sign a photo every time they wanted to rent an apartment, buy a house, or get a hotel room.

The seller/owner would have been required to keep this information in case the Irish person bombed some place and they could begin to track them.

Of course the politician that proposed this instantly rose to the top of the IRA assassination list. I can't remember if it was PM Edward Heath or not. Edward Heath did introduce internment in Northern Ireland where Catholics could be detained and sentenced without a trial. That did lead to a failed assassination attempt by the Balcombe Street Gang.

Re:And other things..

[Anonymous Coward]

I know someone who already ran into the Y2K38 problem. Basically he changed his computer's time to something well beyond 2038 in order to circumvent a copy protection, but Opera wouldn't start after he did that. (If you've got a 64-bit system, try various softwares today!)

Re:And other things..

[STrinity]

I always found it interesting that 1 billion seconds happened 2 days before 9/11.

I don't get it. What's the significance of 111011100110101100101000000000 binary seconds?

Re:And other things..

[Anonymous Coward]

I remember the IRA bombs, they affected me as a child. But rather than implementing such ID schemes, there were daily bulletins on tips and ideas on how to be more vigilant. Check your car for bombs, report suspicious activity, tips which are more likely to prevent terror attacks than today multi million pound/dollar government initiatives.

I think there was more of a threat back then to my personal safety than there is now, but i agree the government is all about post 9/11... There was as many terror attacks 20 years ago as now, just now the media jumps on it more implying that we are approaching judgment day or something.

But this is a digression, in 30 years the world will perhaps it was a long term terror plan to cripple industrialized nations.

Re:And other things..

[SuperStretchy]

From what I hear, Pearl Harbor defines your generation just as much as 9/11 did ours. 9/11 "defining" our nation wasn't just one day, rather igniting almost 7 years of war on terrorism (whereas WW2, while on a much grander scale) lasted 4 years post-Pearl Harbor). Let me do the defining of me.

Re:And other things..

[wattrlz]

Well, some of those 2,999 were very big money makers.

Re:And other things..

[gnuman99]

9/11 was man attacking man. Heck, non-US people attacking US people. Ominous. We got 2 wars with 100,000+ people dead and millions displaced out of this.

'04 Tsunami was nature with man in the way. Happens all the time. The number of casualties was the only thing that was ominous. No wars out of this.

This explains the press coverage.

The "security" stuff is kind of like the old cold war crap. You know, watch out for the "red commies" or "capitalist pigs". How many trillions were spent on that? The people making money just needed another funnel and terrorism/security is it. That's why there is so much more attention now vs. IRA days. The good old saying will probably never die - follow the money.

Re:And other things..

[Gospodin]

11/9 was just big because it was in the US. Anti-US sentiment aside, the US is simply a more influential country than any of those affected by the Tsunami. US has very a powerful media and politic, so of course its going to be well covered.

9/11 was big because it was caused by people. The tsunami was caused by nature. Comparing responses to them is like comparing responses to a murder versus a heart attack.

Re:And other things..

[Malevolent Tester]

I'd say there's a fundamental flaw in comparisons between the current situation and the Troubles - the Provisional IRA/INLA/Continuity IRA/I Can't Believe It's Not the IRA had very limited objectives: they wanted to overturn the pro-Union plebiscites by force and later on, get rich off drug dealing and protection rackets. By contrast, at least some Islamists won't be happy until the Common Law(what "new" Labour have left of it, anyway) is replaced by Sharia and the United Kingdom is part of Dar-al-Islam. Comparing the likes of Gerry Adams and Abu Hamza is like comparing the Falklands War with WW2.

Re:And other things..

[wattrlz]

Considering the fact that the UK officially stopped using the long scale in 1974 and 1,000,000,000 seconds is approximately 30 years, I'm pretty sure it's an, "American" billion.

Re:And other things..

[pdxp]

A dozen: Twelve. That's half of 24, which is only one more than 23. It was a mistake to think I could escape the number! What are you trying to tell me?!

Re:And other things..

[cp.tar]

I always found it interesting that 1 billion seconds happened 2 days before 9/11.

I don't get it. What's the significance of 111011100110101100101000000000 binary seconds?

Well, for one, you have 13 ones and 17 zeroes.
These numbers add up to 30, and you'll notice that 9 is divisible by 3, while 11 is not, so it gets a zero.

Furthermore, 17-8==9; 13-2==11. 8+2==10, which falls right between 9 and 11. Coincidence?

Re:And other things..

[DigitalCrackPipe]

lack of coverage and donations given to the victims of the tsunami
Not sure what numbers you're reading. According to this article on the Tsunami,

In all, the worldwide community donated more than $7 billion (2004 U.S. dollars) in humanitarian aid. It's not very productive to directly compare an event with such political magnitude to a natural disaster, without taking other factors into consideration. Try comparing Hurricane Katrina to the tsunami, and then adjust for scale, for a better idea of how limited the reach of media and donations are.

Re:And other things..

[CODiNE]

Yeah, like no kidding! It must have been so freaky living back then... every year gets smaller and smaller, everyone wonder what's gonna happen after year 1 BC ends. I still can't figure out who picked the starting year they counted down from, strange it was never documented anywhere. Weird times man.

Re:And other things..

[Anonymous Coward]

If you were in the UK at the time, you'd know that the money given by the UK public for the Tsunami relief effort was enormous, more generous per person than other countries.
Your other comments were accurate.
The newly created mythological enemy has caused far more security trouble than the real-life older enemies.

Re:And other things..

[Chysn]

> I always found it interesting that 1 billion seconds happened 2 days before 9/11

Interesting in what way? If the 1 000 000 000-second timestamp happened right as the first plane hit the first tower, then it might be a vaguely interesting coincidence. But how is two days before even remotely interesting?

> [it's] probably one few times that an apocalyptic-like event happened so close to a man
> made time scale.

Not bloody likely.

Re:And other things..

[loki_tiwaz]

there is a possibility that the tsunami was caused by man, if you just google 'tsunami bomb' you'll find that such devices have been in development for quite some time. while i don't discount the theory that it was a purely natural event, it is equally possible it was a successful experiment in the use of triggering natural disasters for military purposes. the tectonic plates between india and indonesia are extremely volatile and it probably wouldn't have taken much to make it violently move so as to cause what we saw happen. i don't know really, but just to point out that humans may have had a direct influence and certainly, indirectly, the region is vulnerable to this kind of event and building so close to the shore in a tsunami-prone region is a major factor in the fatalaties that occurred.

Re:And other things..

[PIBM]

And did you knew that this amount is less than 0.5% of the cost of the war in iraq from the US alone?

Re:And other things..

[mdarksbane]

I remember every charity organization and every school around having some sort of fund raiser to help Tsunami victims. It wasn't that no one in the US cared, it's that it's farther away and affects someone else. Everyone takes care of their own at higher priority than the rest of the world.

Re:And other things..

[Propaganda13]

It's not that interesting.
Pick a start date.
Pick a number.
Countdown that time then look for a major event that happened near that time.

If it was something that happened at that exact second that wasn't caused by humans like an earthquake then that would be interesting.

Re:And other things..

[Anonymous Coward]

Yep an how much was to fund overpaid contractors, brought in from America to advise the locals. Seems like lots of money spent and nothing really to show for it except for some overpaid US contractors/advisers.

Re:And other things..

[whitehatlurker]

what I'd call one thousand million

Don't you folks call 'em "milliards"?

Re:And other things..

[Tango42]

The IRA's bombings weren't (in most cases) intended to kill people, they even gave warnings so the appropriate areas could be evacuated. I guess they just wanted publicity for their cause for the most part. Al Qaeda are very fond of indiscriminate killing, which is much more likely to cause hysteria.

Re:And other things..

[Tango42]

Has your tin foil hat slipped?

Re:And other things..

[JonathanR]

The instruction at 0x49790053 referenced memory at 0x49790053.
The memory could not be read.
Click OK to terminate the program.

Re:And other things..

[p0tat03]

Well... There's still plenty of "not our problem-itis" going around, which isn't a value judgment per se - people naturally value their local community more, and this value drops off as you get further out. For example, plenty of people (magnitudes more than people who died in 9/11) are dying in Darfur, or any other conflicted region in this world, but yet these topics are usually on the 4th or 5th of the paper, if that, whereas a single local murder gets front page attention.

Re:And other things..

[Anonymous Coward]

Hmmm... funny. That would mean the 1 billionth second occurred on my birthday.

Re:And other things..

[Carnildo]

Really?! So there are always at least 12 numerological associations with every event in history?! OMG, I'm totally freaking out!!!12!12!

There, fixed that for you.

Re:And other things..

[Arthur Grumbine]

And of course "12" is composed of the digits 1 and 2.
1+1=2
1*2=2
2/1=2
1+2=1
2^1=2
What does this all add up to...?
9
But don't forgot...
9 + 1*2 = 11
Who has a UID with 9 as it's most common digit?! Bob-taro!!
Whose UID without the 9s = 6+8+8 = 22, That's TWO 2s. 22 divided by 2...you guessed it... 11.
That's right...9...11. 9/11!!!
Who had the most to gain from 9/11?! Bob-taro!!
Who brought down the towers?! Bob-taro!!
Who fired a cruise missile into the Pentagon!? Bob-taro!!

And to think, Bob-taro, you almost got away with it you sneaky sonuvabitch...

Re:And other things..

[Anonymous Coward]

I think Boeing or some aircraft company was one of the first company to run into Y2K problems because of how they plan their building schedule or something. So they might encounter Y2K38 problems.

Boeing, the airline company that's building the 787 in Microsoft's backyard? Nope, sorry, they're a Windows shop, through-and-through.

If they have problems, it won't be because of time_t. According to Wikipedia, "On September 5, 2007, Boeing announced a three-month delay to the first flight, citing a shortage of fasteners and rivets as well as incomplete software".

Yep, the world's largest aircraft factory delayed first-flight because they couldn't find enough rivets.

Re:And other things..

[glitch23]

I think your scales are off. The 2004 tsunami was a massive loss of life (225,000 people in eleven countries) compared to the 2,999 people killed in the airplane attack of 9/11/01.

I was a little appalled at the lack of coverage and donations given to the victims of the tsunami compared to the massive outpouring given to the 9/11 victims. It must just be that fact that I am in America now, and the media / government is so stuck on only looking inside the country and not what happens in other countries (unless it involves oil).

As I mentioned in a post just a few days ago, there is a different between people dying accidentally and people being murdered. Essentially, when comparing an act of God and murder, one is legal and one is not. Even when a person accidentally kills another the sentence is less harsh when compared to the punishment for murder. Yes, almost a quarter million people died in 2004 and many countries sent money to provide assistance. A small percentage of that were murdered 3 years prior to that. We can't help acts of God but we can help murder. Murder should never happen and steps are being attempted to make sure something like the events on 9/11/2001 do not happen again. By the way, there are many places the US has troops deployed and many of them are not in oil-rich countries so your bias against the President because you think he wants oil is unfounded.

Re:And other things..

[maharvey]

Apocalyptic event?

Actually an epochalyptic event.

Re:And other things..

[Matt Perry]

are using the two events (9/11 and 7/7) to push all of these "security" measures.

What is 7/7? Or what happened and in what year? Is that when the tsunami occurred?

Re:And other things..

[glwtta]

Yeah, kind of like how Christ was born so close to the changeover from BC to AD.

I don't know if that's all that impressive - probably quite a few people were born within 4 years of that date.

Re:And other things..

[powerlinekid]

As it probably should...

People care more about what is happening around them than they do 6000 miles away. Its kind of a survival trait...

Re:And other things..

[Torvaun]

The most subtle part of his plan was where he changed 1+2 to equal 1.

Re:And other things..

[Anonymous Coward]

Did you know that the war has nothing to do with donations sent to Tsunami relief?

Re:And other things..

[Tolkien]

Yes but relatively speaking, the influence of a country should definitely be taken into account of your equation.

How much media coverage would the Queen Mum's fatal heart attack (God forbid) get, versus a homeless person's murder?

Re:And other things..

[Anonymous Coward]

The tsunami wasn't caused by people but the deaths certainly were. The huge numbers of deaths in the tsunami were avoidable. They died because their government has less money.

So its more like comparing a murder to 100people dying of starvation. I certainly know where my priorities would be.

Re:And other things..

[hetfield]

If 9/11 defines that generation, then I'm so happy to be an old fart. I never would let a terrorist act define me.

Let me guess. You were born after WWII? There were/still are a lot of people on both sides of the pond that would say that event defined their generation.

Re:And other things..

[Anonymous Coward]

I would have donated but the cost of living here is so high! I mean, do you realize what 20 grams of Cocaine costs these days?

Re:And other things..

[Herby Sagues]

What's your point? If we avoid 200 such Tsunamis we can afford a new war?

Re:And other things..

[HopperUK]

Jesus. I hope you're joking.

Re:And other things..

[Anonymous Coward]

Then compare the response to the Loma Prieta earthquake in California. His argument is still valid.

Re:And other things..

[gr8scot]

Tsunami victims did not try to blow anybody up.

Do not misconstrue that as support for the invasion of Iraq on the pretext of nuclear weapons known not to be there by the elected officials who told the US public that such weapons were in Iraq, and ready to be launched at a moment's notice. PIBM just made a stupid comparison. GWB is still much, much stupider.

Re:And other things..

[Anonymous Coward]

Nobody's scared of right wing wackos, like Timothy McVeigh Or Rupert Murdoch.

Re:And other things..

[oldhack]

Ok, I'm an ignorant American (actually, an ignorant immigrant). 7/7??? What the fuck's that?

Re:And other things..

[PReDiToR]

I am and always have been an Englishman, I left edumacation in 1991 and I was always taught the 'billion' as a million million and that the US used a thousand million for it.

The National Curriculum was in force before I left education.

Were my teachers a little behind or were they die-hard old-timers who refused change?
Another possible explanation is that your 'officially' is [citation needed].

Re:And other things..

[proselyte_heretic]

I'm that generation, and I dont wan't to be defined that way. I was in 4th grade when it happened, and i thought: "Thats really sad, but its only a couple thousand people, it should change my life all that much. Suffice it to say, I was wrong. I misunderestimated the potential for fear in governments and regular people. I dont think that anything less than 10,000 people killed is worth altering all of American life for.

Re:And other things..

[gr8scot]

You were closer at the start with "any number" than with your subsequent "dozen."

You can come up with any number of numerological associations for any event. Seriously. Try it some time. Pick any event, and you can come up with a dozen, if you try.

There are literally infinite numerological associations for any single event. Since the number of associations for any one event is allowed to relate to any number of other single events, and to each of those in any number of ways, this is a "larger infinity" than the set of all real numbers. Of course, it is also completely meaningless, but then, you already knew I was talking numerology, so I just redundantly repeated there what I had already told you implicitly by the very fact of replying to you at all.

Re:And other things..

[Somegeek]

Quote Tango42:

The IRA's bombings weren't (in most cases) intended to kill people, they even gave warnings so the appropriate areas could be evacuated. I guess they just wanted publicity for their cause for the most part.

What IRA are you talking about? The Provos, which is what most people refer to as the 'IRA', were responsible for somewhere around 1,800 deaths during "The Troubles", from the late '60s through the late '90s. During this same period they were responsible for approximately 20,000 wounded.
http://en.wikipedia.org/wiki/Provisional_Irish_Republican_Army#Casualties

Their primary strategy was "A war of attrition against enemy personnel [British Army] based on causing as many deaths as possible so as to create a demand from their [the British] people at home for their withdrawal."
http://en.wikipedia.org/wiki/Provisional_Irish_Republican_Army#The_.22Long_War.22

'as many deaths as possible'.

Re:And other things..

[marafa]

i believe he was referring to the amount of money spent as being out of proportion
for example you say the US donated 1billion for the victims. other sources say the US has upped the military budget by as much as 100billion a year.

of course, with the tsunami it is an act of god, where as the iraq and afghan war was an "act of economics" (C)(R) (patent pending)

dig?

Re:And other things..

[Matt Perry]

Jesus. I hope you're joking.

Nope. Not joking, just curious. I don't keep up with news. I didn't know about the tsunami until a few weeks after it happened.

Re:And other things..

[Schemat1c]

What is 7/7? Or what happened and in what year? Is that when the tsunami occurred?

Jesus. I hope you're joking.

Nope. Not joking, just curious. I don't keep up with news. I didn't know about the tsunami until a few weeks after it happened. Curious enough to write 2 posts on Slashdot but not enough to type "7/7" into Google, unless of course you've never heard of Google.

Re:And other things..

[raehl]

You forgot the most obvious - 853723: 8 + 5 + 3 + 7 = 23. This chicken farmer has a name: Topsy Kretts. Watch out!

What? It's TOTALLY Michael Jordan.

Re:And other things..

[DiscipleN2k]

When I type "7/7" into Google, Google tells me it's "1"

Then it goes on to mention something about a bombing in London.

Re:And other things..

[Matt Perry]

Curious enough to write 2 posts on Slashdot but not enough to type "7/7" into Google, unless of course you've never heard of Google.

If you had tried that, like I had before posting the first time, then you would have seen that Google thinks that you want to divide 7 by 7 and returns an answer of one. It's frustrating that people would rather respond and argue than just either answer or ignore my post that was made in good faith. Anyway, just forget it. I guess it's not that important in the grand scheme of things.

Re:And other things..

[Schemat1c]

When I type "7/7" into Google, Google tells me it's "1" Strange because when I typed it I got this. Maybe you are using a different Google.

Re:And other things..

[Henkc]

0.0026% and "massive" do not compute.

Re:And other things..

[Anonymous Coward]

On September 11 2001, 36,000 children died in Africa of hunger. And every day ever since. Is there a war on hunger? No. Who gives a shit about some children in Africa anyway?

Re:And other things..

[Anonymous Coward]

The Queen Mum died in 2002, it wasn't a heart attack, but perhaps the media coverage was not so good?

Re:And other things..

[aproposofwhat]

Groups like the IRA and ETA are generally composed of local people fighting on what is basically a local issue.

We understand the causes of their frustration, and their targets were / are generally predictable.

The PIRA in particular rarely bombed without telephone warnings, usually accurate enough to allow an evacuation to take place.

Bin Laden, on the other hand, holds beliefs that are alien to our culture, and unbelievers sit next to dogs on his scale of values.

Islamic extremist bombers are unlikely ever to give adequate telephone warnings, since they value human life far less than the Catholics of the PIRA and ETA.

Having said that (and probably being of an age with you, having grown up in the late 60s and early 70s), the current rage for intrusive and unwarranted legislation is, I believe, more of a product of the CYA culture and the 'preventative approach' mentality than it is a reflection of any real threat.

Intelligence and law enforcement agencies have empires to build and budgets to inflate, and politicians have no spine in the face of public (read Daily Mail) opinion, so I see little hope of this trend ending soon.

Re:And other things..

[Bazer]

I guess he calculated in base 3 and forgot to type the 0.

Re:And other things..

[ingvar]

A mere piffle. Some nutters strapped bombs to themselves and blew up on the London Tube and on a couple of buses. Nightmare getting to work that day (yes, I had a "start late" week) and the mobile phone networks were all overloaded. Some people died, that is sad. Some people were maimed, that is sad too. But I refuse to budge and cower in fear.

Re:And other things..

[16Chapel]

The IRA didn't just plant bombs - they shot taxi drivers, grenaded army barracks, kneecapped people etc. etc.

Yes, the IRA gave warnings before they bombed, but don't think that meant they were honorable or nice and fluffy - they sometimes gave deliberately false and confusing warnings that led to more deaths / injuries to innocent civilians (see the Omagh Bombing: http://en.wikipedia.org/wiki/Omagh_bombing)

Don't get me wrong: the loyalist groups were just as bad. Most of the deaths in the Troubles were not bomb victims but tit-for-tat killings between Catholics and Protestants, as one side retaliated against the other in a horrible spiral of violence.

Re:And other things..

[whereareweheadedto]

Your information is correct. But you forgot to mention the difference between car bombs in urban areas, which were reported in advance (although sometimes questionable police response made matters worse: http://findarticles.com/p/articles/mi_qn4156/is_20011209/ai_n13963053 http://www.rinf.com/columnists/news/mi5-and-omagh-the-bomb-to-end-all-bombs ) and the actual attacks on British colonial forces, which were meant to hurt them. I see the war in N Ireland as a classic war for independence with all modern "appendages". Unfortunately it's not over yet and Irish people are still under foreign rule. Before you go yapping about and accusing me of supporting "terrorists" think about your own country. Wherever you are. Almost every country had its war for independence. The only question is when and how successful was it against its colonial masters. Overlords, if you will.

Re:And other things..

[camusflage]

I was a little appalled at the lack of coverage and donations given to the victims of the tsunami compared to the massive outpouring given to the 9/11 victims.

Simple. Politicians couldn't get any votes by vowing to protect the US from tsunamis, to go after tsunamis and the earthquakes that cause them, launching preemptive strikes at fault zones before they unleash their tsunamis, etc.

Re:And other things..

[smoker2]

What I find interesting are the dates themselves.
9/11 is the US emergency service telephone number, and is in the US date format.
7/7 means nothing in the UK (outside the bombings) BUT the date format is ambiguous.
Was this date chosen specifically to garner sympathy from the USA ?
Hmmmm ....

Re:And other things..

[The Spoonman]

No, but it does take money away from other efforts.

Re:And other things..

[jimdouglass]

Perhaps you would feel more comfortable moving back to where you came from if being HERE is so difficult for a person of your obivously high intellect and world view.

Re:And other things..

[kalirion]

No, it's more like comparing responses to a murder versus a plague.

Re:And other things..

[aproposofwhat]

Yes, I know the PIRA did all those things - sectarian and organised crime related violence and murder were their stock in trade, along with their Loyalist counterparts.

Bombings of military targets were never accompanied by warnings - the view of PIRA was that they were at war with the British state, but not with the British people.

Omagh is a special case - that was the 'Real IRA' splinter group, made up of the most recalcitrant and unbending psychopaths who rejected the Good Friday peace process.

Now that the political process appears to be working, I have high hopes that the cycle of violence won't break out again in Northern Ireland, and even that a united Ireland might be possible once the Unionists see that it's in their long term interests.

Re:And other things..

[wattrlz]

I was unable to turn up any particularly compelling citations, so I'll just point you to the wikipedia article on the subject which includes a few references that would point to the fact that, as of 1974, for financial documents, media announcements, official reports and statistics, etc. the accepted meaning of, "billion" is, in the UK, 10^9.

I guess the million-million thing you've observed is just an informality akin to how american children, were in my experience, and perhaps still are, spared the dissection and vicissitudes of most of the curriculum until secondary education.

Re:And other things..

[enjerth]

No, but it does take money away from other efforts. Other efforts, like planning on having a future? Like giving our children a prosperous country to live in?

*Sigh*

Yeah, those things are about gone now.

Re:And other things..

[bloobloo]

The majority in Northern Ireland want to remain part of the UK. Reference: http://www.ark.ac.uk/nilt/2005/Political_Attitudes/NIRELAND.html

Re:And other things..

[Tango42]

I wouldn't count an attack against armed forces as terrorism. It's just war. Most attacks against innocent civilians were not intended to kill.

Re:And other things..

[The Spoonman]

Really? And, how exactly does initiating a war with what is essentially a third-world country do that? Hmmm? With the money that's been spent on the war so far, we could've given every person in the US free healthcare, increased the educational standards across the board AND come up with a clean, cheap alternative to fossil fuels. I would say that would make our country a lot more prosperous than killing our children to clean up "Gee, Dubya's" father's mistakes and REALLY pissing off those terrorists the pussy 'pubs are so afraid of.

I think the problem is you forgot to remove your head from your ass this morning.

Re:And other things..

[enjerth]

I think the problem is you forgot to remove your head from your ass this morning. You seem to have missed something. Like what I said. I was replying to someone who said the money used on the war could have been used for other efforts. Actually, what I should have said is that we shouldn't have spent that money at all.

Deficit spending is driving this country into the ground, and fast. People are always talking about the terrible debt, but so few people actually take it seriously. Free health care is the answer. Yeah.

We will soon be an impoverished nation. As the dollar drops and wages remain steady, the federal poverty line creeps up a few thousand dollars every year, and it's not even keeping up with inflation!

It's not true that, when the tide rises, all ships rise with it. The ones sitting on the bottom just find themselves further under.

Re:And other things..

[The Spoonman]

My apologies. Slashdot sent me the alert that your reply was to me. When I hit the site, it continued to appear that way.

As for free health care, yes, it would help as the cost of our reactive healthcare system is higher than being proactive. All of the suggestions I made (healthcare, education and alternative energies) are proactive measures that reduce costs in the long run and allow the US to become a productive member of the world society again. There's a reason that the one industrialized nation that doesn't provide for the care and education of its populace is quickly sliding down the ladder.

Re:And other things..

[mikechant]

The majority in Northern Ireland want to remain part of the UK. Reference:

Presumably in response republicans would say that Northern Ireland was artificially carved out of Ireland with a deliberate built in unionist majority (by choosing the particular 6 counties which would form NI), so this majority was effectively gerrymandered.

(Although personally I don't feel sufficiently well historically informed to take a position on this one way or another)

Re:And other things..

[Tango42]

Gerrymandering is only a problem when local areas are making choices which affect a large area (for example, electing a representative to national government). Choosing just those counties that have a majority wanting to be part of the UK to be part of the UK isn't gerrymandering, it's giving the people what they want. Whether NI is part of the RoI or the UK doesn't really affect anyone other than those living in NI, so NI having the choice only makes sense.

Re:And other things..

[Anonymous Coward]

Epochalypse Now!

Re:And other things..

[FictionPimp]

You would think, that with a shortage of food, you would stop reproducing so quickly. Then eventually, the food/person ratio would come back into check.

Re:And other things..

[Anonymous Coward]

" I was a little appalled at the lack of coverage and donations given to the victims of the tsunami compared to the massive outpouring given to the 9/11 victims. It must just be that fact that I am in America now, and the media / government is so stuck on only looking inside the country and not what happens in other countries"

Little information was available right after the tsunami due to the lack of resources (there were no foreign news reporters on site, power and functioning communications lines were wiped out) in the area where the tsunami hit the worse. Additionally, the Indonesian government ordered U.S. ships away from their coast line and greatly restricted access by foreign journalists and aid workers, because they didn't want the Indonesian people to know that the first responders and most aid was coming from "non-Islamic" countries.

Also, the United States especially was derided over the paltry $15 million in aid offered within a day or two of the tsunami actually happening. This was rapidly increased to $35 million, then $350 million. A month and a half later, a $950 million aid package was approved. The reason for the initial small offering is because no one fully understood the shear magnitude of the tsunami, due to lack of information coming out of the region. On a personal note, I heard about the tsunami the morning of Dec. 27, 2004 and thought that was an unfortunate incident. It was an entire week before I saw on the news the true extent of what had really happened. At that point, I basically took my paycheck for that month and dropped it in the mail.

In total, the US put forward over $2.8 billion in aid to the region; the total from the entire world totaling around $7 billion.

It was still a couple of months before the world knew just how devastating the tsunami really was. The only reason we have images of the tsunami is because of the videos taken by tourists on vacation by the beach. Yet those videos only captured the light part of the tsunami. There were regions where entire towns were wiped away with no survivors! When rescuers arrived at one location where no one had been heard from for over a month, evidence on what buildings were still standing suggested that the wave had actually crested as high as 100 feet above the ground.

I prefer to focus on the fact that people desperately wanted to do whatever they could to help and did so.

Hmmmmmm

[LithiumX]

I spell profits on the wind...

*sniffs himself*

Yeah, it's the wind.

Re:Hmmmmmm

[nullCRC]

No, that was me. Sorry.

Re:Hmmmmmm

[homey of my owney]

How the hell is the parent moded off topic? A lame joke perhaps, but the reference to profit is right on the money. I mean, have we forgotten what 1999 was like?

Re:Hmmmmmm

[forkazoo]

I spell profits on the wind...

Wait, are you a wizard, or did you misspell smell as spell? I mean, I don't usually nitpick this sort of thing, but when the parent post specifically references spelling or grammar, I feel okay about it. And, well, you did use the word "spell," which IMHO counts as a spelling reference.

Anyhow, just let me know if you spell magic missile on the wind, so I know if I need to duck, or get a dictionary, or something.

Re:Hmmmmmm

[LithiumX]

Spell = smell Me = idiot non-proofreading mouth-breather

Re:Hmmmmmm

[Sanat]

What is even stranger is there are still sites out there with "Jan 19108" on them. So after 9 years since 1999 some sites still need updating.

Guess if it ain't broke then don't mess with it syndrome.

Man, it sure doesn't seem that it has been that long ago.

Re:Hmmmmmm

[PReDiToR]

He who denied it ... Supplied it.

I can't wait!

[ucblockhead]

I plan on making a mint using my mad C skillz in 2036 and 2037, just like all those Cobol guys who came out of retirement in 1998.

Re:I can't wait!

[peragrin]

If we are sill running 32 bit software in 2038 I will fully blame MSFT.

I would be surprised if 70% of the comptuers in use by 2020 would still be 32 bits. Not with most of the newer processors today at 64 bits. Experiments in 16 core 128 bit computers to toast your bread in the morning should be happening by 2020.

Re:I can't wait!

[ucblockhead]

The trouble isn't the OS. The trouble is application code written to assume that time is a 32 bit value. I've no doubt that there is code like that around still. (Though I highly doubt much will be in operation in 30 years.)

Re:I can't wait!

[plague3106]

Why would you blame MS? They've had 64 bit OSes for some time now. Exchange Server 2008 is 64-bit only. So why exactly would you blame them?

Re:I can't wait!

[truthsearch]

Though I highly doubt much will be in operation in 30 years. ... said the COBOL developer in 1970...

Re:I can't wait!

[lawn.ninja]

good luck with that. John Titor already solved the problem when he came back in his GE206 Temporal Displacement Unit to pick up that IBM 5100. Duh.

Re:I can't wait!

[petermgreen]

stuff has a nasty habbit of sticking arround longer than you expect. You plan a system to last say 10 years at the companies current growth rate. After say 7 years your company reaches it's growth limit and becomes an income company or worse there is a rescession in your industry and your company teeters on the edge of bankrupcy. The system keeps running with few changes until it is say 20 years old at which point the hardware is becoming difficult to obtain but noone really understandards how the system works so rather than trying to port it they put it on an emulator. Before you know it the code has been running for decades.

File formats also have a nasty habbit of sticking arround longer than the software that works with them and file formats very often contain embedded binary date formats that were chosen simply because they were the default types for the platform in question.

Re:I can't wait!

[Anonymous Conrad]

If we are sill running 32 bit software in 2038 I will fully blame MSFT. But 32-bit OS can still use 64-bit numbers. And they do! In fact Windows's native time format *is* 64-bit.

Re:I can't wait!

[blair1q]

Parts of that Linux kernel you're typing on haven't changed in 18 years.

Variables whose choice of basic type involves an assumption of any kind leave open just this sort of risk that the use-case space left unimplemented by the assumption is entered.

People understand the Y2K kind of date error. But there are hundreds if not thousands of such assumptions made - and not documented - in coding any program of significant size.

Re:I can't wait!

[Anonymous Coward]

Nice defence, but the product is Exchange Server 2007, not 2008.

Re:I can't wait!

[pla]

Before you know it the code has been running for decades.

...And I've retired, problem solved.

Mmmm, sweet sweet post-retirement contracting income! And just about on the right schedule for me, too! Time to start making my code as dependant on 32-bit timestamps as possible (Stupid Windows with its 64-bit "100 nanoseconds since 1/1/1601", trying to rob me, the bastards!). ;-)

Re:I can't wait!

[tepples]

If we are sill running 32 bit software in 2038 I will fully blame MSFT. Microwaves still run 8-bit software. Retro-gaming fans still run 8-bit games in emulators. The Animal Crossing game for GameCube terminates its simulation in 2030.

Re:I can't wait!

[elrous0]

Sepaking as one of the many Terminators sent back to kill John Titor, I can assure you that he will not be returning home, with or without his precious 5100.

BTW, if anyone has any idea where he is, please email me. My job is really on the line on this one.

Re:I can't wait!

[ConceptJunkie]

Choose your reason:

1. Everyone hates Microsoft. People feel they deserve derision even when it's not their fault.
2. It's an easy target. Microsoft has the kind of track record that makes people expect them to screw up.
3. Complexity. Good code or not, Microsoft has so much code that there's bound to be a problem somewhere.
4. Because it's probably going to happen. Face it, It wouldn't be the first time that a bug has been unearthed after more than a decade in Microsoft code. They've shown an uncanny level of innovation when it comes to finding ways to screw up even the most simple things.

Re:I can't wait!

[plague3106]

Everyone hates Microsoft. People feel they deserve derision even when it's not their fault.

Which is irrational.

It's an easy target. Microsoft has the kind of track record that makes people expect them to screw up.

Thier track record as of late has been pretty good.

Complexity. Good code or not, Microsoft has so much code that there's bound to be a problem somewhere.

No doubt. But a problem so severe that people can't migrate to 64-bit? Very doubtful, given that they have had 64 bit support for a few years now.

Because it's probably going to happen. Face it, It wouldn't be the first time that a bug has been unearthed after more than a decade in Microsoft code. They've shown an uncanny level of innovation when it comes to finding ways to screw up even the most simple things.

Yes, they can screw things up. But so much so that it actively keeps people from moving to 64-bit hardware? Again, I think this is doubtful.

Re:I can't wait!

[darrinallen]

I remember the problems with the COBOL Year 2000 problem. I was a Cobol Mainframe programmer. I think we spent around 6 months planning. We only had a couple of problems when the New year did approach

Re:I can't wait!

[Anonymous Coward]

I plan on making a mint using my mad C skillz in 2036 and 2037, just like all those Cobol guys who came out of retirement in 1998.

I thought the same thing until I remembered that the World is scheduled to end abruptly in 21 December 2012 according to the Maya calendar.

Now if I can find a bank open on Saturday

[Actually, I do RTFA]

I can get a thirty-year $250,000 loan with monthly payments of -$1,200.

Re:Now if I can find a bank open on Saturday

[risk one]

Just hope they're using signed ints to store that value.

Re:Now if I can find a bank open on Saturday

[NathanWoodruff]

You can already do that today.... http://www.reversemortgage.org/ Nathan

Re:Now if I can find a bank open on Saturday

[bee-17]

Just today in the mail, I got a letter from Countrywide pitching a home loan:

YOUR ESTIMATED EQUITY MAY BE AS MUCH AS $-48,331

Coincidence?

Re:Now if I can find a bank open on Saturday

[Actually, I do RTFA]

Just hope they're using signed ints to store that value.

Actually, I think they use floats. See, I wrote this program to - everytime there is a transaction where interest is computed, and there are millions a day, this program rounds it down to the nearest cent and puts the remainder in an account...

Re:Now if I can find a bank open on Saturday

[rk]

Given the housing market, that could be pretty accurate. :-/

Re:Now if I can find a bank open on Saturday

[3vi1]

Did you base your program on the one In Office Space, or the one in Superman 3? If it was the one in Superman 3, you're totally screwed because the libraries are GPL instead of LGPL and now your entire project has to comply with the license.

Oh god... I forgot this is slashdot: now someone is going to spend 30 minutes composing a reply that explains how the GPL doesn't work like that....

Re:Now if I can find a bank open on Saturday

[WK2]

Just hope they're using signed ints to store that value. Actually, I think they use floats.

Nope. They use two integers. One for the dollars, and one for the cents. Some older programs get fancy and use a special 4 (or 6, or 8)-byte number, where 7 (or 8) bits are used for the cents, and the rest for the dollar signs. These are known as "fixed-point fractions." The important thing to keep in mind is that floating point numbers are not accurate enough for banks.

Re:Now if I can find a bank open on Saturday

[mattmatt]

Too bad you always put the decimal point in the wrong place...

Re:Now if I can find a bank open on Saturday

[gr8scot]

Assuming you're not just making that up, you're the person to ask the question I've been wondering since reading the headline, and a couple lines of the article.

Nope. They use two integers. One for the dollars, and one for the cents... The important thing to keep in mind is that floating point numbers are not accurate enough for banks.

Why not do something similar for time -- an int for the year, another for the month, another for the day, and another for the time of day?

Re:Now if I can find a bank open on Saturday

[Eivind]

Are you certain ? More commonly you'd use -one- integer that stores simply the number of cents. $73.50 stored simply as 7350, simple and effective. Has the benefit that all the standard mathemathical operations simply work, without needing to track dollars and cents separately.

Re:Now if I can find a bank open on Saturday

[qazsedcft]

I happen to work with large banking systems. Actually, currency data is usually stored as a single fixed-point number in the DB. When the data is passed around between systems it's just plain old strings, but I can assure you that many of those systems actually process currency data using floating-point numbers.

Re:Now if I can find a bank open on Saturday

[Anonymous Coward]

So he'd have Superman and RMS! on his back?

Re:Now if I can find a bank open on Saturday

[DarkOx]

Exactly look at any ERP system like JDE One World or similar. You find it mostly stores currency values as numeric with no decimal values and simply works with all values multiplied by 10000.

Its really a nice way to solve the problem.

Re:Now if I can find a bank open on Saturday

[Samster33]

I think thats called "Salami Slicing". I love it! Just make sure your calculations are correct so you don't slice off too much money :)

The answer is 64!

[SeanMon]

By 2038, no major consumer cpu manufacturer will be producing anything but 64 bit chips.

Re:The answer is 64!

[Anonymous Coward]

I was hoping for a 1024bit CPU by 2038.

Re:The answer is 64!

[91degrees]

They might... After all, transistor computers were up to 32 and 36 bits before the first 4-bit microprocessor was introduced. It is possible that a revolutionary new concept in processing will result in an insanely fast processor but technological limitations will force it to only be 8 bits.

Re:The answer is 64!

[Anonymous Coward]

Please elaborate on why you think having 64-bit hardware will fix issues where software is using a 32-bit (more specifically, 31 bits plus a sign bit) integer type to represent the number of seconds since the start of 1970.

Re:The answer is 64!

[Anonymous Coward]

You mean upgrading to a 64bit cpu won't fix all the bugs in my code? The horror!

Re:The answer is 64!

[KillerBob]

Considering that they were making 8-bit chips in 1972, 16-bit chips in 1979, 32-bit chips in 1986 ('386 was a 32-bit chip... SX was 32-bit internally on a 16-bit bus, and DX was 32-bit bus too), and by 1991 64-bit chips (the DEC Alpha leaps to mind). Even today, most graphics processors are 128-bit chips, and I believe there's even some 256-bit processors on the horizon for NVidia/ATI if they aren't already here. I suspect that by that time 2038 rolls around nobody will still be producing lowly 64-bit chips. Probably by that time even 256-bit chips will be considered antiques.

Re:The answer is 64!

[_KiTA_]

By 2038, no major consumer cpu manufacturer will be producing anything but 64 bit chips.

My good sir, by 2038, no major consumer CPU manufacturer will be producing anything but 256 bit chips. At the very least.

Re:The answer is 64!

[Jorophose]

Yes, but what happens to my lowly Pentium 2s?

Do you honestly think everyone's going to dump their old PCs to the curb?

(As sad as it is, I know plenty of people do this, but not geeks.)

Re:The answer is 64!

[thegrassyknowl]

Put simply, a lot of software is poorly written and uses int as synonymous with time_t (or somesuch). The two are often interchanged by programmers; particularly those with a Windows background who can't find CTime (or whatever it's called) on non-Windows platforms.

Moving to 64-bit machines won't fix all the magic 32-bit binaries out there but software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int.

Of course, I've seen a lot dumber bugs than ignoring to use the operating system's time structures and methods for dealing with time so I don't doubt that there are some bugs that actually will need some serious considerations made.

I guess it's a fault of the Unix people from way back. They made this epoch thing and used a 32-bit number to store the number of seconds since it. I guess they were assuming that all their software would have been replaced by something better on bigger machines. They shouldn't have written such reliable software and then maybe some of it would have been replaced by now ;)

Re:The answer is 64!

[Curien]

It's not "31 bits plus a sign bit". It's (usually) two's complement.

Your point about hardware upgrades not mattering is a good one, though, and was in fact made by TFA.

Re:The answer is 64!

[frieko]

I'd like to point out that thanks to the carry bit, an 8-bit CPU can do 64-bit math. In fact, any Turing-complete device can do 64-bit math. This is strictly a software issue.

Re:The answer is 64!

[Anonymous Coward]

"640-bits are more than anyone will ever need."

But seriously you say that now but just wait until the zombie apocalypse and a pointy stick is state of the art technology.

Re:The answer is 64!

[Anonymous Coward]

but software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int.

This isn't by any means "automagic." Just because it's compiled for a 64-bit CPU doesn't mean that all ints become 64 bits in length.

Sizeof(int) on my 64-bit machines still gives 4. That's right, still 32 bits. This is completely in line with the standards, which give lower bounds to integer sizes.

To ensure 64 bits you'll have to use a long long in each place you use int.

Re:The answer is 64!

[EdSchouten]

No, it isn't. This is not related to the address space size of the hardware that's used. The reason why systems haven't switched to 64-bits is to remain compatible with current implementations. It would be quite evil if some binary thinks gettimeofday() is going to return a 32+32-bits structure, while in reality the kernel smacks a 64+32-bits structure in there.

I don't know much about Linux, but I do know that FreeBSD uses 64-bits time_t's on all architectures, except PowerPC and i386. You can easily see this by running the following commands:

FreeBSD box running i386:

$ date -j -f %s 233453453464
Failed conversion of ``233453453464'' using format ``%s''

FreeBSD box running amd64:

$ date -j -f %s 233453453464
Thu Nov 5 14:31:04 CET 9367

In 2038 almost nobody will use a 32-bits operating system on their PC's. Even if some people really *need* to do this, they can just change the time_t definition on their system and recompile everything. Nothing to see here. Move on.

Re:The answer is 64!

[Neil Hodges]

Why don't you try checking your Linux sources as far as time_t is concerned:

% grep time_t asm-x86_64/posix_types.h
typedef long __kernel_time_t;

The AMD64 Linux kernel uses long integers to store time. This type is given more names as the code gets further away from the kernel, and is eventually typedef'd as time_t.

Re:The answer is 64!

[Anonymous Coward]

What about Hamilton '95? A true 44-bit OS FTW!

Re:The answer is 64!

[zienth]

thegrassyknowl said:
I guess it's a fault of the Unix people from way back. They made this epoch thing and used a 32-bit number to store the number of seconds since it. I guess they were assuming that all their software would have been replaced by something better on bigger machines. They shouldn't have written such reliable software and then maybe some of it would have been replaced by now ;)

Well, the Unix people from way back were writing for a PDP-11, which was a 16 bit machine. I'd guess their early compilers didn't have an int type with more than 32 bits. Actually, since the Unix kernel was originally written in assembly, they may have used a 32-bit int because anything bigger was just a pain to write code with. I'm not sure whether a 32-bit time_t was in use before they re-wrote the kernel in C in 1973 or not. Keith

Re:The answer is 64!

[cnettel]

Naively, though, there seems to be limited reason to store integers that are on the order of the square of the number of electrons in the observable universe. This means that we should stop at 256, if not earlier. There are pure physical reasons for why will never use up that address space for any kind of real memory. With limited use for the numbers, and limited use for the addresses, increasing the width seems quite strange. The bus width is a different thing, of course, and you can have a maximum word for SIMD operations, but by that logic all Pentium Ms are 128-bit chips already.

Re:The answer is 64!

[Rodyland]

software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int.

Umm... no.

Depending on your architecture (x86, sparc for two) and compiler (sunpro for one), 64bit compilers may still define an int as 32 bits, but redefine long, time_t, size_t, ptrdiff_t etc. as 64-bits (and FYI long long is also still 64bits).

So, if an programmer has typed

int i = time(NULL);

then that code is still going to have the Y2K38 bug in it when recompiled in a 64 bit environment.

Re:The answer is 64!

[HTH NE1]

software is using a 32-bit (more specifically, 31 bits plus a sign bit) integer type Um, why was it not an unsigned int? Was the need for negative time greater than having an epoch spanning to 2106?

Reasonable limits aren't.

Re:The answer is 64!

[rk]

Wow... Good times. I haven't thought of that in years. Reference for you young whippersnappers.

Re:The answer is 64!

[Blkdeath]

Yes, but what happens to my lowly Pentium 2s?

Do you honestly think everyone's going to dump their old PCs to the curb?

(As sad as it is, I know plenty of people do this, but not geeks.)

By the year 2038, your Pentium 2s will have long died and been replaced with "lowly Pentium 4s", which will then have been replaced by those "antique quad-core Xeons", etc. ad nauseum.

There just comes a time with commodity hardware where it reaches its EOL. When I upgrade my computer the internal hardware goes like this; Workstation --> home server --> parents --> younger brother --> curb. When I was still "hard core" I'd have a second machine in there because, well, let's face it - you just need two up-to-date workstations!

Neither my parents or my brother have had to buy a computer since the Compaq Presario with a Pentium 120 was considered "high end". As a matter of fact I've just given my brother my old 17" CRT monitor and taken the old Presario monitor for my server because the antique I was using went pop.

Point being, eventually everything dies. Eventually 64-bit processors will be the equivalent of the Celerons of yesteryear. Quad core will be passe. These will be the CPUs we use in our test boxes, or our "just has to pass packets" firewall machines, or the machines we give to computers for schools programs.

Heck, I don't even have any hardware in use today from the Pentium II era and the slowest processor in my family is about 800MHz and as of now it's a dog.

Re:The answer is 64!

[CastrTroy]

I think it's quite stupid that the definition of "int" changes every time we change architectures. This caught me a few times in my first year programming course. The compiler I had at home was 32 bit, but for some reason the machines in the lab were configured to compile for 16 bit. They were windows 98, with some version of Borland, but for some reason, all my integers which worked fine at home, would overflow like crazy as soon as I brought them into the school computer lab.

Re:The answer is 64!

[PReDiToR]

Will a 256bit processor and OS be able to run a calculator that defines PI more accurately than 3.1415927?

Re:The answer is 64!

[HonIsCool]

Assuming you were programming in C, you should have followed the standard if you wanted portability. The C standard guarantees that int is at least 16 bits. If you need larger values, use long.

Re:The answer is 64!

[Alioth]

People will still be producing "lowly 64 bit" chips (that will probably still be the main architecture for desktop systems - and by the way, the VAX was 32 bit in 1979). 8 bit chips are incredibly common today, probably outselling 32 bit and 64 bit chips by 10 to 1. Embedded systems tend to be 8 bit. The Z80 is still manufactured (and there are new versions of the Z80 - still 8 bit - but you can buy a brand new, made in 2007 Zilog Z80 in a 40 pin DIP, which will plug straight into a Z80 based home computer from 1980). Microcontrollers like the Atmel AVR and Microchip PIC are 8 bit.

Re:The answer is 64!

[vegiVamp]

> I guess it's a fault of the Unix people from way back.
> They shouldn't have written such reliable software

I knew it! We should have all just shut up and take it dry up the ass from the Gates kid, then none of this would have happened.

Re:The answer is 64!

[doti]

Moving to 64-bit machines won't fix all the magic 32-bit binaries out there but software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int. Not quite. On Linux/GCC the time_t is 64-bit, but the int is still 32-bit. That is, moving to 64-bit will only fix it if the programmer uses the correct type (time_t) for holding the time. Sadly, most programmers don't.

Re:The answer is 64!

[Karellen]

Really, if you want to ensure 64 bits, you should use int64_t. Unless you might be porting to systems that don't have 64-bit ints, but might have other longer ints which would suffice, in which case use int_least64_t. Of course, if you just want as big an int as the architecture can handle, use intmax_t.

Re:The answer is 64!

[Evil Pete]

Agreed but the problem is, of course, that the programmer should have written:

time_t i = time( NULL );

Re:The answer is 64!

[cnettel]

256 bits is rougly 256/10*3 > 76 digits of accuracy. If we want floating point, we need to devote some of that to the exponent, let's say we keep the mantissa at 200 bits. Then we still have 60 digits, or More Than Enough(TM) (especially since you can do arbitrary-precision arithmetics anyway if you really want to).

Re:The answer is 64!

[xZgf6xHx2uhoAj9D]

These types are a huge abomination to C, as far as I'm concerned. There is no way to write standard C where the exact size of an integer is needed. My only hypothesis for why int64_t and int32_t and the like were included in the standard is to appease giant dumbasses who write integers directly to binary files, a practice which of course is not conforming to the standard.

The C integer types are, in fact, very logical, very useful, and very much your friend. Here's a quick guide:

1. If you need to store some portable task-specific value, then use the type provided for that purpose (e.g., time_t, size_t, intptr_t, ptrdiff_t, ...)
2. Otherwise, by default, use int. An int is guaranteed to be the most "natural" size for your architecture (it's up to the compiler to determine what "natural" means, but just trust your compiler: use "int" unless you have a reason not to)
3. If you are storing massive arrays/structs and wish to save memory, and are confident your values won't fall below -32767 (note not -32768: the C standard does not guarantee 2's complement) or above 32767, then use short
4. If you are confident that your values will fall below -32767, or above 32767, then use a long
5. If you are confident that your values will fall below about -4 billion or above about 4 billion, then use a long long
6. The most important point: never just dump an integer into a binary file (as through fwrite). The most portable way to read and write files is through text, of course, as text is guaranteed to be portable by the C standard. This is not always practical, and in the real world binary files are needed, but make sure to write your data portably. Do not assume signed integer representation (e.g., 2's complement), do not assume exact integer sizes, and do not assume 8-bit bytes. None of these things is guaranteed by the standard.

The types mentioned above will do everything that the int64_t, int_least32_t, etc. types will provide. intmax_t seems equally useless. Contrary to the parent's suggestion, the C standard says nothing along the lines of intmax_t providing the largest int that an architecture can handle. What would that even mean? That it's the biggest int that can be stored in a register? Oops, I guess x86 can't have a 64-bit intmax_t then, eh? That it's the biggest int that the architecture can perform arithmetic on? Well then I guess on most architectures, intmax_t must be at least a couple billion bits in size, right? There's no meaningful definition of this sort can be used.

What the standard says about intmax_t is, and I quote, "The following type [intmax_t] designates a signed integer capable of representing any value of any signed integer". That's it. All it says is that an intmax_t can store any value from a signed char, short, int, long, or long long. In other words, as far as the standard is concerned, there is no difference between a long long and an intmax_t. And indeed, I would be very surprised if there were ever an architecture where intmax_t were not just a synonym for long long: after all, there is no way to write conforming C code where an intmax_t can be depended on to do anything that a long long won't.

So why would you ever use an intmax_t? You wouldn't. There's no reason to. If you're writing conforming code.

Re:The answer is 64!

[Karellen]

Uh, how about for reading and writing binary data formats?

How about struct sockaddr_in, which uses a u_int16_t? Or struct in_addr which uses a u_int32_t? Or struct sockaddr_in6?

How about describing structs to read ELF headers into? You'd probably want a number of these to read and write (for example) 32 and 64 bit executables on not-necessarily-native architectures if you want to play with them. What about JPG or PNG headers?

Not all people who design binary file formats are "giant dumbasses who write integers directly to binary files" - they *need* to specify the sizes of fields in the format so that portable readers/writers can be written that work on multiple platforms. Text formats are kind of interesting, but they're not useful in *all* circumstances.

Previously, all programs pretty much needed their own autoconf or other deep magic/wizardry to probe the system they're being compiled on and generate their own typedefs for these types. Which is a lot of work and prone to fuckups. Having standardised names for these types is entirely sensible for the legitimate cases where they are needed.

And as far as I'm concerned, long long is more of a fuck up than the named types. The only reason that's there is to support dumbasses who assumed that short is 16 bits, int is 32 bits and long is 32 bits, and whose shitty code would break if any of these changed.

But this does remind me of one good use for the fixed types though. IMO, of 64-bit systems, int should be 64 bits. long therefore ought to be 128 bits. What about short? Hmmm....probably 32 bits. Now what if you need 16-bit integers? e.g. as a struct member for loading binary data. Or as a means to parsing UTF-16 (or UCS-2) text? Sure, you could use char[2] and then convert it/them yourself to and from 32-bit shorts, but that's going to be a real pain. Much easier to just use an int16_t.

Re:The answer is 64!

[petermgreen]

You can call people who read and write integers or stuctures containing integers direct from binary files or binary network protocols dumbasses all you like but the fact is that the only alternatives for reading and writing binary files are both slow and cumbersome.

Yes you have to be carefull about endian issues and maybe if you want to support some very obscure platforms (which most people don't care about supporting sorry) and used signed numbers in your file signed number representation but that is why we have functions like htons. htonl ntohl and ntohs).

Re:The answer is 64!

[xZgf6xHx2uhoAj9D]

You make a good point. The way I would look at it is in those cases you're already making assumptions (8-bit bytes, 2's complement, etc.), you may as well make some other assumptions. I guess the nice thing about int32_t and the such is that, in the cases where you are making these sorts of assumptions, you don't have to typedef these themselves. It saves a little bit of #ifdef hell.

Re:The answer is 64!

[xZgf6xHx2uhoAj9D]

It is actually not difficult to portably read/write binary files. It may be a little time consuming, but you only have to do it once. For example:

void
write_long(long x, FILE *f)
{
  if (x < 0)
    write_long(~(-x), f);
  else {
    unsigned char c;
    c = (x & 0xff000000) >> 24;
    if (fwrite(&c, 1, 1, f) != 1) { ... }
    c = (x & 0xff0000) >> 16;
    if (fwrite(&c, 1, 1, f) != 1) { ... }
    c = (x & 0xff00) >> 8;
    if (fwrite(&c, 1, 1, f) != 1) { ... }
    c = x & 0xff;
    if (fwrite(&c, 1, 1, f) != 1) { ... }
  }
}

And you'd need read_long, write_int, read_int, write_short, read_short, etc. etc. It relies on the fact that the C standard guarantees: characters are AT LEAST 8 bits; sizeof(char) = 1; longs are AT LEAST 32 bits in size. I force the value into 4 8-bit characters comprising a 32-bit 2's complement number, regardless of what underlying representation the architecture uses.

Yes, true, fwrite(&x, 4, 1, f) is more efficient, but not so conforming or portable :P

long long was added to create an integer which is at least 64 bits in size. It was created because people needed integers longer than 32 bits. It has nothing to do with people making assumptions.

I don't see why an int should be 64 bits wide on a 64-bit machine. It's not any faster; it doesn't save any cycles anywhere. The general rule of thumb is to use "long" if you need a long integer. Consequently, people who use int are (theoretically) doing so because they don't need a long integer. Seeing as there is no performance penalty, I think using 32-bit integers on a 64-bit machine is fairly prudent just for the memory savings.

Re:The answer is 64!

[xZgf6xHx2uhoAj9D]

Oops there is a bug in my write_long. That's what I get for coding off the top of my head. Regardless of my bug, hopefully the sentiment still gets across that you only need to write these functions once, and it shouldn't be TOO hard to code them.

Also note that these functions will use for things like the PNG header or a TCP header. It's just a little more portable, that's all.

Re:The answer is 64!

[Anonymous Coward]

The idea of simply waiting for a 64 bit machines to replace 32 is the same faulty planning that led to the y2k scare, people assuming that systems now in use would dissappear before the problem became an issue. There may still be 32 bit systems in 2038, and there may already now be software effected by this, if it is some sort of prediction software that deals with future dates. What really is needed is a new time/date API in the OS which returns 64 bit dates, even on 32 bit systems. Then software can be converted gradually as needed to use this new API.

Re:The answer is 64!

[petermgreen]

The way I look at it is

8 bit bytes and 2's complement are de-facto standards so I am pretty safe in assuming them.

On the other hand the size of "char" "short" "int" "short long" "long" "long long" and so on does vary considerablly by platform. By defining the fixed size integer types as part of the standard libraries the application programmer is freed from having to maintain (update whenever porting to a new platform) thier own set.

Byte order also varies by platform and again there are standard routines (as part of the berkely sockets API) for converting between host byte order and big endian byte order (which is the internet standard) so the application programmer doesn't have to maintain thier own set.

Re:The answer is 64!

[Rodyland]

Indeed, and believe me when I say that trawling through code to change ints to time_ts or size_ts is neither as fun or as easy as it sounds when previous programmers have used int/long/size_t/time_t interchangeably.

Re:The answer is 64!

[Karellen]

"I don't see why an int should be 64 bits wide on a 64-bit machine."

Um, because it would make sense for an unadorned "int" to be the same size as the native integer type for any given arch. On a 64-bit arch, the native integer type ought to be 64-bits. That's what a 64-bit architecture is.

"It's not any faster; it doesn't save any cycles anywhere."

Really? There are no (and will be no) 64-bit architectures where working with 32-bit ints isn't slower (due to needing to mask the value, or correctly do overflow, or ...) than 64-bit ints? What about when 128-bit arches come out? Will using a 32-bit "int" still make sense then? 64-bit arches are not just x86-64...

"[long long] was created because people needed integers longer than 32 bits."

And "long" is perfectly capable of being defined as 64-bit and dealing with that need. But no-one defines "long" as 64 bits. Why might that be?

"long long was added to create an integer which is at least 64 bits in size."

Yes, but long long was not invented by the C99 standards committee. It originated as a proprietary extension in compilers (I think GCC had it first) as there was/is a *lot* of code out there that does make assumptions about "int" and "long" sizes. People needed to start using 64-bit integers, but the compiler folks couldn't alter "long" to do that as all the existing code that relies on "long" being 32-bit would break.

Yes, all that code does make bad assumptions that are not backed up by the C standard. Yes, that sucks. But, being the pragmatists that they are, compiler vendors still realised that if they (never mind how legitimately) changed those assumptions and broke users code, users would not upgrade to new versions of the compiler, or would just use a different compiler instead. So, the compiler vendors added "long long" as a workaround.

A large part of the job of the C99 standardisation committee (and the C89 committee) was to codify existing practice as much as possible and to break as little existing code as possible. "long long" going into it is a result of this. The exact defintion is what it is in order to be inline with code that was already out there. "int[foo]_t" is their (much more rational, IMO) attempt to codify other existing practice (plenty of people define their own fixed-size data types) and make the language more future-proof. What happens when they want to add 128-bit numbers to the standard? Would you prefer that "long long long int" be added? Or does int128_t make a bit more sense?

And I think your function will fuck up if char is 16-bits. You'll put 8-bits of x into each of 4 16-bit chars, and then write out 4 16-bit bytes, making 64 bits in total written. Whereas fwrite(&x, sizeof(x), 1, f) would still work if x was an int32_t on a system with 16-bit bytes. (For values of "work" that do not include endianness issues :-)

Re:The answer is 64!

[Anonymous Coward]

"Moving to 64-bit machines won't fix all the magic 32-bit binaries out there but software that's recompiled for 64-bit machines will automagically use 64-bit ints where the programmer held the time in an int."

Which operating system are you using, exactly?

Unix systems (and OS X) are usually LP64. This means long and long long are 64 bits wide, while int is *still* 32 bits wide.
Windows is LLP64. This means long long is 64 bits wide, while int is *still* 32 bits wide.

Re:The answer is 64!

[petermgreen]

By 2038, no major consumer cpu manufacturer will be producing anything but 64 bit chips.
If by consumer cpu manufacturer you mean those who made desktop PC orientated chips you are right but they are only a tiny fraction of the overall processors sold. Also I don't see 32 bit compatibility support in PC processors going away in the forseeable future (current PC processors can still run 16 bit code!)

but even if your system has been moved to a 64 bit platform and is compiled natively rather than using a 32 bit compatibility mode there are still two big problems.
* for efficiancy many 64 bit platforms define int as being 32 bit (the integer types that matches the size of a pointer isn't nessacerally the fastest integer type). Through laziness or ignorance many programmers use int when they should use time_t.
* many file formats, network protocols and databases almost certainly have 32 bit unix style timestamps designed in. Databases are fairly simple (a simple alter table or similar) but conversion may require quite some downtime. File formats and network protocols may be much harder.

Re:The answer is 64!

[xZgf6xHx2uhoAj9D]

Really? There are no (and will be no) 64-bit architectures where working with 32-bit ints isn't slower (due to needing to mask the value, or correctly do overflow, or ...) than 64-bit ints?

Why would you need to mask anything? I think you misunderstand what an int being 32 bits means. That doesn't mean that it only uses 32 bits in the register. A 32 bit int can use 32 or 64 or 128 or 4096 bits in a register. There is absolutely no point in masking it in the register to keep it contained within 32 bits. Yes, it might start overflowing into the 33rd or 34th bits, or sign extend all the way into the 63rd bit. Who cares? That has no visible effect in the program.

What makes the int "32 bits" is when you start reading from or storing to memory. When you start pushing an int onto the stack, do you use a "st" (store word) or "std" (store double-word)? (Using SPARC's instructions). Aside from storing and loading, 32-bit and 64-bit arithmetic is exactly the same, even in 64-bit registers.

I'm less versed in x86-64, so I can't say conclusively that there are no performance penalties there for working with 32-bit data, but on SPARC and PowerPC at the least, a 64-bit int offers no performance advantage over a 32-bit int.

And "long" is perfectly capable of being defined as 64-bit and dealing with that need. But no-one defines "long" as 64 bits. Why might that be?

I am a C programmer. I need an integer which is at least 40 bits long. What do I use? A long? It's possible than a long is 40 bits long, but it's not guaranteed. Therein lies the difference.

People needed to start using 64-bit integers, but the compiler folks couldn't alter "long" to do that as all the existing code that relies on "long" being 32-bit would break.

That might be why compiler folks invented long long, but it is not why the C standard adopted long long. As I said before, people need a guarantee of an integer longer than 32 bits. long will never be guaranteed to be longer than 32 bits.

What happens when they want to add 128-bit numbers to the standard? Would you prefer that "long long long int" be added? Or does int128_t make a bit more sense?

You're thinking about this from the wrong perspective. If compiler writers want to add a 128-bit integer, they are perfectly within their right to make a long long, or a long, or an int, or a short, 128 bits in length. The standard is not there to satisfy compiler writers (okay I lie a little bit, but it's a mental exercise).

The standard is there to provide guarantees about what C programmers can expect. Do C programmers need a guarantee that, on all platforms, under all compilers, there is an integer type at least 128 bits long? If yes, then the C standard should add a type to support that (probably long long long). There are different mentalities behind the phrase "using a 128 bit integer".

One mentality is that just happens to be what the compiler gave you. You know, "I used long because I only required 32 bits, but the compiler gave me a 128-bit integer because it would be just as natural. Bonus!" In that light, it's obvious why compiler writers are so free to go beyond the requirements of the standard.

The other mentality is that you need a 128-bit integer. In that case, using a long is totally out of the question, no matter if your compiler provides a 128-bit integer or not. If you ever want your code to run with a different compiler, you have to use a new type (say long long long), because that's the only one that guarantees the length you need.

Re:The answer is 64!

[xZgf6xHx2uhoAj9D]

But no-one defines "long" as 64 bits.

FYI, a number of compilers do define a long as 64 bits. It's called the LP64 model (longs and pointers are 64 bits long), and Microsoft and Linux/GCC follow it for 64-bit platforms, if I remember right. I've heard rumours of some compilers even following the ILP64 model (ints, longs and pointers are 64 bits long), though as I said before, I don't think that's the greatest idea.

WTF are you talking about?

[avandesande]

"Some 30-year loan calculation software might start having problems with this over the weekend."

WTF would this have to do with an interest calculation???

Re:WTF are you talking about?

[plague3106]

Well, its kind of hard to compute payment dates if your date representation ends at 2038, and you have something longer than a 30 year mortgage.

Re:WTF are you talking about?

[Anonymous Coward]

Last payment date, things like that.

Re:WTF are you talking about?

[zulater]

The raw calculation won't have a problem but maybe in displaying/storing the amortization table there could be a hiccup. You're not going to get out of your mortgage or anything but it's interesting none the less.

Re:WTF are you talking about?

[gstoddart]

"Some 30-year loan calculation software might start having problems with this over the weekend."

WTF would this have to do with an interest calculation???

Presumably, the amortization table will fall of the end of the Earth and your last payment will be due in 1970.

I must admit, I'm not going to start worrying about this stuff. Hell, that's probably longer than I'll even be alive. :-P

Cheers

Re:WTF are you talking about?

[riseoftheindividual]

A lot of loan calculation software does more than just calculate interest rates. They can also produce payment schedules and amortization over the life of the loan, up till the last payment.

Re:WTF are you talking about?

[avandesande]

Ever hear of 40 year loans? There is nothing 'special' about this weekend.

Re:WTF are you talking about?

[avandesande]

Yeah, and most loan deals are put together weeks or months before closing. We would have already heard something by now.

Re:WTF are you talking about?

[cnettel]

Actually, it would probably be in 1901, since the overflow only takes place for signed ints. We'll have another bug for unsigned 32-bit ints in 2106 or so.

Re:WTF are you talking about?

[everphilski]

I haven't worked on finance software, but when you are looking at time-dependant data on satellites you don't use unix time you generally use an algorithm. There are relatively straightforward algorithms that start from a pre-defined day-one and will generate a calendar at day x in the future.

Re:WTF are you talking about?

[gstoddart]

Actually, it would probably be in 1901, since the overflow only takes place for signed ints. We'll have another bug for unsigned 32-bit ints in 2106 or so.

Oh, well, that changes everything ...

Run for your lives everyone, we're all gonna die!! :-P

Cheers

Re:WTF are you talking about?

[cheater512]

Are you sure? I was under the impression that it was unsigned 32 bits.

Re:WTF are you talking about?

[Anonymous Coward]

I work for a VeryBigBank, and I can assure you we are worried about this problem, though not excessively. Personally, I don't understand why this problem didn't surface at least 10 years ago. 40+ year securities are not common, but they do exist.

Re:WTF are you talking about?

[cnettel]

Are you sure? I was under the impression that it was unsigned 32 bits. 4294967296 / 365 / 86400 = 136 2147483648 / 365 / 86400 = 68 (yeah, leap years conveniently ignored)

Re:WTF are you talking about?

[el_gordo101]

So the bank will be trying to foreclose on you for being 100+ years late on your last payment before you are scheduled to make your first. Awesome!

Re:WTF are you talking about?

[Anonymous Coward]

I'd hate to see the late fee for that payment.

What loan software uses Unix time?

[corsec67]

And, wouldn't 50 years or longer loan terms have shown this before now?

Re:What loan software uses Unix time?

[Surt]

There aren't vast numbers of 50 year loans like there are 30 year loans. It's likely that the volume of 50 year loans, handled on systems with this problem, and with software which is vulnerable to some sort of wrap error, is small enough that they've been handled manually.

There are truly huge numbers of 30 year loans out there. Tens of millions, on thousands of different systems. This is much more likely to be a sufficiently common problem to really hit the public notice, and should have some reasonable chance of actually requiring some programming intervention to correct.

Re:What loan software uses Unix time?

[crabpeople]

50 year loans? Are you nuts? Pretty much everyone alive will be dead in 50 years, doubbley so if you count the people old enough to take out a loan (20+).

I cant believe such a thing exists. Can you imagine its 2058 and you just finished paying off your 2007 silverado!

Re:What loan software uses Unix time?

[Pseudonym]

Plenty of extant corporations will be around in 50 years.

Re:What loan software uses Unix time?

[swb]

I've read that 50 year loans are popular in Japan, although it ties in there to much higher real estate costs for property purchase, as well as a greater cultural tendency for the home to be lived in by extended families. So when you turn 80 and pay off the loan, you are still living there, but then so are your kids and their kids.

Re:What loan software uses Unix time?

[EchoNiner]

I work at a fixed income bank (one of the ones in the news). Although we don't have 50 year loans, we do have 40 year loans in sufficient volume. Most places that deal with loans would've seen amortization issues way before this on these guys and no, they wouldn't have solved them manually, they do number in the thousands.

Re:What loan software uses Unix time?

[etwills]

And, wouldn't 50 years or longer loan terms have shown this before now?

You'd have thought so, although it's a somewhat minor problem as long as you can store the date for the next meeting successfully. ...recalls the local bowling alley League Coordinator stating "Y2K year rollover problems? With the PDP11-based scoring system we recently* retired, we've been dealing with that sort of thing for some time now".

*in 1997!!!

30 years?

[Hatta]

Remind me again when it's 30 minutes.

Re:30 years?

[geekoid]

The headline is worded odly, but what they are saying is that the 30 year will be over on the 19th of this month, this year. in 4 days.

Re:30 years?

[MikeDirnt69]

Global warming, pollution, violence, 'religion' wars, resource (oil/food/etc) wars, etc... Don't worry, nobody will see that bug happening.

Re:30 years?

[garett_spencley]

Really. Anyone who can't upgrade their CPU from 32-bit to 64-bit with 30 minutes notice really isn't qualified to use a computer.

/ attempt_at_humour

Re:30 years?

[CSMatt]

"Some experts claim the ball might return to Earth someday, but their concerns were dismissed as 'depressing.'"

Re:30 years?

[mixmatch]

Its 2038 already? I must have missed it.

maybe vba has a chance to live then

[circletimessquare]

as vba doesn't have this limitation like that child's toy they call unix

Re:maybe vba has a chance to live then

[Anonymous Coward]

wow. your an idiot.

but then again you already knew that!

Re:maybe vba has a chance to live then

[KublaiKhan]

However, isn't MS removing support for that? Seems to me that I'd rather use a "child's toy" for the next 30 years rather than an unsupported bit of nonsense that'll be replaced ten or fifteen times by then.

Re:maybe vba has a chance to live then

[ari_j]

The phrase "your an idiot" is one of my favorites almost in the English language.

Re:maybe vba has a chance to live then

[daeg]

I think your sarcasm detector is broken...

Re:maybe vba has a chance to live then

[KublaiKhan]

Must be. Dang thing never works properly on Tuesdays.

Re:maybe vba has a chance to live then

[calebt3]

It's written in VBA.

Re:maybe vba has a chance to live then

[Anonymous Coward]

obvious troll is obvious.

Re:maybe vba has a chance to live then

[onkelonkel]

"Your an idiot"

Zhwip...Doingg!

You just broke my irony meter. That sound was the needle wrapping itself around the stop pin at the red end of the scale.

Re:maybe vba has a chance to live then

[Linker3000]

Yep - and change it to "you're and idiot" and the phrase is completely within the English language ;-)

Re:maybe vba has a chance to live then

[twentynine]

no u

Re:maybe vba has a chance to live then

[Allnighterking]

Why does it always have to be my an idiot, Why can't it for once be someone else's an idiot. I keep my an idiot clean, it doesn't talk out of turn or make rude noises. But everyone just likes to pick on my an idiot.

Re:maybe vba has a chance to live then

[PReDiToR]

That only means it would break on Patch Tuesdays, how about submitting to bugzilla if it doesn't work on any Tuesday?
Could have it fixed by 15:00 =)

Re:maybe vba has a chance to live then

[Paul server guy]

Actually, it's "You're an idiot" but I agree, that is certainly one of the best, Right beside "Kiss my what?!" and "Coffee, Double strong, Double sweet."

Re:maybe vba has a chance to live then

[Anonymous Coward]

How about the tee shirt that says:

                  YOUR
              RETARDED

Re:maybe vba has a chance to live then

[ari_j]

I actually have no idea why you like "You're an idiot," which is far more puzzling than the likelihood that someone would miss the humor in what I wrote. You, sir, have confused me.

Re:maybe vba has a chance to live then

[Paul server guy]

Mostly because I have to live and work with them daily, and I am not known to be a people person...

Envy

[argmanah]

I envy the programmers who had the foresight to program their application using a 2 digit year field. They won't have to worry have to worry about this problem until 2099, and by then we won't be using the same systems we do today anyways!

Re:Envy

[joker784]

Hm, that depends on which language you are using - I have seen a couple of examples of scripts that interpret numbers starting with zero as an octal number, and these scripting laguages have a hard time with 08 and 09 - saying that these numbers are not integers! Languages include Tcl, Perl and Ruby.

Re:Envy

[Anonymous Coward]

Laugh you may but will programmers in the late '9990s get the joke?

Re:Envy

[mzs]

I JUST ran into a script like that! It made a bunch of us here chuckle. Guess how and when we ran into it.

Re:Envy

[glwtta]

I have seen a couple of examples of scripts that interpret numbers starting with zero as an octal number

That would only come up with hard-coded values, though; so it may lead to some funny programmer cock-ups, but won't be affected by changing dates. I'm pretty sure there isn't a language insane enough to treat user input that way (or at least no relatively popular language insane enough).

Re:Envy

[jmy]

man strtol.3:

          The string may begin with an arbitrary amount of white space (as deter-
          mined by isspace(3)) followed by a single optional `+' or `-' sign. If
          base is zero or 16, the string may then include a `0x' prefix, and the
          number will be read in base 16; otherwise, a zero base is taken as 10
          (decimal) unless the next character is `0', in which case it is taken as
          8 (octal).

So basically all C-code which parse user input with base == 0 get that behaviour.

And I would call C relatively popular. Insane is harder to define though.

Bah

[jconley]

Everyone's getting 50 year loans now anyhow, there won't be a problem with the date calc.

There may be an overflow when they calculate how much interest they are paying though...

My date of birth

[nogginthenog]

Is 123456789, Unix time. No shit. 29 Nov 1973. Guess I'm a confirmed geek then?

Re:My date of birth

[scaverdilly]

Yeah, but 1234567890 comes just short of Feb 14th in a year (Fri, 13 Feb 2009 23:31:30 UTC).
It just goes to show that true geeks will only ever almost get close enough to women for romanitc encounters.

Re:My date of birth

[wizardforce]

you know your birthdate down to the second, that's impressive.

Re:My date of birth

[Nos.]

So you were born Thu, 29 Nov 1973 15:33:09 -0600? If you're going to say you were born at 123456789 epoch time, then you are specifying down to the second.

Re:My date of birth

[Anonymous Coward]

would be cooler if it started 1337..... :-)

Re:My date of birth

[Compholio]

[My date of birth] Is 123456789, Unix time. No shit. 29 Nov 1973. Guess I'm a confirmed geek then?

I'm sure your mom appreciates that just as much as having you at 11:30 PM GMT.

Re:My date of birth

[choongiri]

My birthday is January 19th. Does that mean I'm going to expire due to some kind of horrible fatal error on my 57th birthday?

Re:My date of birth

[Anonymous Coward]

Is 123456789, Unix time. No shit. 29 Nov 1973. Guess I'm a confirmed geek then?

Is your SSN 123-45-6789? If so, this is the sign geeks have been waiting for. Deliverance is near!

Re:My date of birth

[Chosen Reject]

I know my daughter's. Well, I could if I was wearing the shirt my brother made for me that has her name written in binary and her birth date/time in unix time on the bottom. I love that shirt. For some reason my wife doesn't dig it as much. Go figure.

Re:My date of birth

[Pseudonym]

Heretic! The Saviour of All Geeks shall be born on an even power of two.

Re:My date of birth

[Anonymous Coward]

Hey, that's my Social Security number as well!

Oh sh

Re:My date of birth

[cashman73]

Holy shit! That's the same combination that I have on my luggage! =)

Re:My date of birth

[Anonymous Coward]

What a coincidence; that's the combination to my luggage!

Re:My date of birth

[Anonymous Coward]

as opposed to an odd power of two.

Re:My date of birth

[xaxa]

2

(2^0 for those without the font.)

Re:My date of birth

[xaxa]

Slashdot killed my unicode :-(

Re:My date of birth

[flyingfsck]

Oops, my birth date has a sign fault...

Re:My date of birth

[joshuac]

Even so I'd still select a UNIX based pacemaker over a Windows CE one.

Re:My date of birth

[Anonymous Coward]

That's my birthday!

Re:My date of birth

[VE3MTM]

Personally, any pacemaker capable of multitasking worries me. Pacemakers have a single task.

Re:My date of birth

[shannara256]

So, you're saying that would-be geek parents have to conceive in May of this year, and optimally induce labor on Friday the 13th of February, 2009? Mark your calendars...

Re:My date of birth

[serialdogma]

Provided it does not use cooperative multitasking I'm fine with it, but this rather exclude MacOS.

Re:My date of birth

[Anonymous Coward]

The true geeks have their wedding date (and time) engraved on their bands in unix time. 1207429200

Re:My date of birth

[Man Eating Duck]

Slashdot killed my unicode :-(

Yeah, I know. If only we had some way of previewing our posts before submitting :)
*ducks*

Re:My date of birth

[Anonymous Coward]

You are wrong. There are many geeks who have wifes and **** them from time to time. Some of them don't even use glasses. There are also hundreds of non-geeks who have never had sex and why is that? Don't judge people of how they life their lifes and how they look or you might experience exactly the same things as the ones you talk about.

sry if my english isn't good. I'm not from a English speeking country.

Sounds good to me

[edwardpickman]

So long as it wipes out my 30 year loan I don't have a problem here. Now if we can get this to work on my five year car loan......

Re:Sounds good to me

[Bert64]

Just buy a more expensive car...

Re:Sounds good to me

[Amiralul]

Yup, my bank still uses a kind of DOS program when I pay my loan. I think it's FoxPro or something. I was thinking of changing to the new modern bank opened recently, but now I will twice about moving to a bank that in 5 years will use Vista.

January 19, 2038

[Malevolent Tester]

Is this going to affect the Duke Nukem Forever release?

Re:January 19, 2038

[teslar]

Is this going to affect the Duke Nukem Forever release?

Naw, don't worry.
Although the second teaser might get delayed.

Re:January 19, 2038

[Zaphod The 42nd]

No, as Duke Nukem will never come out. Luckily, when UNIX time breaks, a wormhole through space will open up and someone will be sent forward in time to infinity A.D., where they may then purchase Duke Forever and return to our time with it intact.

Re:January 19, 2038

[El_Oscuro]

I'm am getting ready to install Duke Nukem Forever on my Linux machine, but first I have to apply the DST patch to the Restaurant at the End of the Universe's time turbines to prevent the space/time continuum from actually being broken.

Re:January 19, 2038

[Anonymous Coward]

LOL! good one.

64, 128, 256...

[Nom du Keyboard]

By 2038 I'd expect everyone to be on 64-bit processors, if not 128- or 256-bit hardware. Even at 64-bits, I won't live long enough for that clock to run out, although it will make some of my favorite hobbies (counting the number of atoms in the galaxy) a lot easier.

Re:64, 128, 256...

[cnettel]

There might still be enough file formats and other stuff where the word width is preserved, or embedded systems that people simply forget about (or where an existing design continues to be used simply because there is nothing wrong with it, except the epoch that happended to be used for the dates). It might seem like just another reason to bash MS, but a few years ago (hm, maybe it was back in 2001 or something) the RTC in my machine went awry. I didn't notice for a few hours/days (not sure), as only the date was affected. The first thing I noticed consciously was that Age of Empires II wouldn't play. When I tried to fix it, I realized that some other seemingly arbitrary things on the Windows machine didn't work. Finally, I noticed that the year was well into the 2040s. By trial and error, I concluded that most of the issues I experienced were related to the 2038 bug. Note that none of these things actualy showed as a date handling error, just sudden termination and crashes.

Re:64, 128, 256...

[Sam Douglas]

You *can* work with data type sizes larger than your CPU's word size in software. For example, if you need to add/subtract 128 bit integers, it is not terribly difficult to do -- it just takes multiple instructions and using the carry-out/overflow bit on you adder. Don't think that a hardware 'improvement' will magically fix software. It is just convenient to use 32 bit numbers as they can be operated on in a single instruction on most modern architectures. Also, increasing the width of your CPU datapath is not something that can be pushed up forever. A simple 256 bit adder would require at least 768 inputs/outputs. At some point it becomes a lot more efficient to change your approach!

Re:64, 128, 256...

[Bob-taro]

By 2038 I'd expect everyone to be on 64-bit processors, if not 128- or 256-bit hardware

Not to nitpick, but a system's cpu instruction and date representation don't have to be the same bit length. An 8bit computer could use 64bit dates and be safe, and a 128bit computer could use a 32bit date and have a problem.

Re:64, 128, 256...

[thegrassyknowl]

I won't live long enough for that clock to run out

At 64-bits the universe probably won't live long enough to see the clock run out unless they do something stupid and start counting picoseconds. 64-bit time will last us another 290 billion years.

Re:64, 128, 256...

[lgw]

Windows uses 64-bit file times everywhere now, and has for years. Probably in reaction to the 49-day uptime limit on Win9x (where the 32-bit "ticks" counter - ms of uptime - would roll over).

Very expensive NAS boxes still use 32-bit file time. It's odd, really.

Re:64, 128, 256...

[SL Baur]

Also, increasing the width of your CPU datapath is not something that can be pushed up forever. A simple 256 bit adder would require at least 768 inputs/outputs. At some point it becomes a lot more efficient to change your approach! Yes. Consider also L1 cache issues - memory access is already larger than machine word size. I suspect fundamental machine word size changes will be hardware driven based on RAM address size and disk/file sizes. 64-bit math will last us for awhile. 32-bit machines had an effective lifetime of over four decades and that's pretty good.

Re:64, 128, 256...

[Greyfox]

By 2038 Google will have attained sentience and destroyed humanity in nuclear holocaust. After re-engineering the planet's atmosphere to be more machine-friendly by eliminating those pesky critters that excrete poisonous oxygen, the 2038 bug will roll around and cause the machine-equivalent of an aneurysm. This will result in the Earth becoming a permanent lifeless husk with no future hopes of recovery. Good going, UNIX programmers!

Re:64, 128, 256...

[Anonymous Coward]

Oh yeah? Well let's just see about that:

4294967297

There. Did your computer just crash?

Not that big a problem

[nog_lorp]

Well, applications that use dates ~26+ years ahead may have trouble, but nothing else will, since the world is going to end on 2012!

Hold on hold on!

[Anonymous Coward]

What's Unix?

Unix is made of *FAIL*

[Gordonjcp]

VMS has been Y10K-compliant for over a decade.

Re:Unix is made of *FAIL*

[ewilts]

> VMS has been Y10K-compliant for over a decade.

It's much better than that. It's mostly DCL that has the year 9999 issue. For those of you who like history lessons and how to design real operating systems (and customer support, back when it actually existed), read this article:

  38 Why Is Wednesday November 17, 1858 The Base Time For VAX/VMS?

COMPONENT: SYSTEM TIME OP/SYS: VMS, Version 4.n

LAST TECHNICAL REVIEW: 06-APR-1988

SOURCE: Customer Support Center/Colorado Springs

QUESTION:

Why is Wednesday, November 17, 1858 the base time for VAX/VMS?

ANSWER:

November 17, 1858 is the base of the Modified Julian Day system.

The original Julian Day (JD) is used by astronomers and expressed in days
since noon January 1, 4713 B.C. This measure of time was introduced by
Joseph Scaliger in the 16th century. It is named in honor of his father,
Julius Caesar Scaliger (note that this Julian Day is different from the
Julian calendar named for the Roman Emperor Julius Caesar!).

Why 4713 BC? Scaliger traced three time cycles and found that they were
all in the first year of their cyle in 4713 B.C. The three cycles are 15,
19, and 28 years long. By multiplying these three numbers (15 * 19 * 28
= 7980), he was able to represent any date from 4713 B.C. through 3267 A.D.
The starting year was before any historical event known to him. In fact,
the Jewish calendar marks the start of the world as 3761 B.C. Today his
numbering scheme is still used by astronomers to avoid the difficulties of
converting the months of different calendars in use during different eras.

So why 1858? The Julian Day 2,400,000 just happens to be November 17, 1858.
The Modified Julian Day uses the following formula:

      MJD = JD - 2,400,000.5

The .5 changed when the day starts. Astronomers had considered it more
convenient to have their day start at noon so that nighttime observation times
fall in the middle. But they changed to conform to the commercial day.

The Modified Julian Day was adopted by the Smithsonian Astrophysical Obser-
vatory (SAO) in 1957 for satellite tracking. SAO started tracking satellites
with an 8K (non-virtual) 36-bit IBM 704 computer in 1957, when Sputnik was
launched. The Julian day was 2,435,839 on January 1, 1957. This is
11,225,377 in octal notation, which was too big to fit into an 18-bit field
(half of its standard 36-bit word). And, with only 8K of memory, no one
wanted to waste the 14 bits left over by keeping the Julian Day in its own
36-bit word. However, they also needed to track hours and minutes, for which
18 bits gave enough accuracy. So, they decided to keep the number of days in
the left 18 bits and the hours and minutes in the right 18 bits of a word.

Eighteen bits would allow the Modified Julian Day (the SAO day) to grow as
large as 262,143 ((2 ** 18) - 1). From Nov. 17, 1858, this allowed for seven
centuries. Using only 17 bits, the date could possibly grow only as large as
131,071, but this still covers 3 centuries, as well as leaving the possibility
of representing negative time. The year 1858 preceded the oldest star catalog
in use at SAO, which also avoided having to use negative time in any of the
satellite tracking calculations.

This base time of Nov. 17, 1858 has since been used by TOPS-10, TOPS-20, and
VAX/VMS. Given this base date, the 100 nanosecond granularity implemented
within VAX/VMS, and the 63-bit absolute time representation (the sign bit must
be clear), VMS should have no trouble with time until:

      31-JUL-31086 02:48:05.47

At this time, all clocks and time-keeping operations within VMS will suddenly
stop, as system time values go negative.

Note that all time display and manipulation routines within VMS allow for
only 4 digits within the 'YEAR' field. We expect this to be corrected in
a future release of VAX/VMS sometime prior to 31-DEC-9999.

Re:Unix is made of *FAIL*

[WilliamSChips]

As a coincidence, nobody has actually used VMS in over a decade.

Re:Unix is made of *FAIL*

[morgan_greywolf]

Yeah, but just you wait and see....VMS will succumb to to Y100K bug! Oh, wait...

Re:Unix is made of *FAIL*

[pokerdad]

It is named in honor of his father, Julius Caesar Scaliger (note that this Julian Day is different from the Julian calendar named for the Roman Emperor Julius Caesar!)

That was a very interesting post; I had not heard of that concept before. However, being intrigued by it I looked elsewhere for more information on it, and found that the information you posted was incorrect on one point

Note: although many references say that the Julian in "Julian day" refers to Scaliger's father, Julius Scaliger, in the introduction to Book V of his Opus de Emendatione Temporum ("Work on the Emendation of Time") he states, "Iulianum vocavimus: quia ad annum Iulianum dumtaxat accomodata est", which translates more or less as "We have called it Julian merely because it is accommodated to the Julian year." This Julian refers to Julius Caesar, who introduced the Julian calendar in 46 BC.

Re:Unix is made of *FAIL*

[kindbud]

That's not funny!

Re:Unix is made of *FAIL*

[hughk]

Go to one of the largest all-electronic markets in the world: www.deutche-boerse.com and www.eurexchange.com. They use VMS and are still waiting for other systems to catch up!!!!

NM - I'm an idiot.

[geekoid]

I kept reading that damn post. It didn't make sense to me. I was like Why is this important? some part of my mind must have made a flip to try and make sense ogf the article.

Anywho..., my bad I apologize.

End of the world

[timmarhy]

Lots of over priced consultants will charge a fortune to fix a problem we negated years ago, then when the day comes and nothing happens they will claim it's a resounding success.

Re:End of the world

[moosesocks]

WRONG.

This isn't like the Y2K bug, where it was "assumed" that poorly written software using 2-digit years would start to behave erratically, whereas programmers had taken this into account in all but the most basic of applications many many years ago. (Due to the manner in which the UNIX timestamp works, the Y2K bug was never an issue on the platform for applications that used the standard UNIX timestamp)

However, the current 32-bit UNIX timestamp WILL unequivocally stop working in 2038, and will cause an integer overflow in any application that relies upon a 32-bit UNIX timestamp. Simply put, it doesn't know how to count any higher. (Any software using MMDDYYYY won't directly be affected, although any routines that "translate" between UNIX and human-readable dates will fail).

Modifying the function time_t() to return a 64-bit value would solve the problem, but would cause major headaches for existing applications, as 64-bit and 32-bit data types are not inherently interchangeable. Backwards compatibility would be completely broken for virtually every application, making this option impractical.

Although 64-bit systems do not suffer this problem, 32-bit systems will most likely see the introduction of a time_t_64() function to return a 64-bit timestamp, which will require programmers to modify their code to ensure that timestamps are stored in 64-bit data types, and to convert existing stored time data to the new format. As long as we can standardize this in the near future, 30 years should be enough time for developers to modify their applications to make use of the new function.

Around 2020, kernel developers should then officially depreciate the 32-bit time_t(), and modify it so that it prints an obnoxious message to the console (perhaps along with a superfluous series of beep()s) whenever the antiquated function is called to alert users of exceedingly lazy developers.

It's not a *huge* deal just yet, but it would certainly be prudent to standardize a method of dealing with this on 32-bit systems NOW so that it doesn't become a problem in the future, especially since we can't say with 100% certainty that 32-bit devices will have disappeared by 2038.

Re:End of the world

[Anonymous Coward]

time_t is a data type, and not a function. But other than that nitpick, nice comment.

2038!?!!

[FudRucker]

by the time 2038 gets here i will be 76 years old (too old to care anymore), i don't want to think that far in to the future...

Re:2038!?!!

[LWATCDR]

Yep it is last my retirment date as well.
Doesn't matter since I hard code all my programs to fail on my 70th birthday anyway.
Just kidding.

Re:2038!?!!

[mwburden]

At least until your pacemaker calculates that it doesn't need to beat again for 30 years....

Re:2038!?!!

[Kyokushi]

Dude, you got a pacemaker that runs UNIX? I want one too!

Re:2038!?!!

[lawrencebillson]

Your grammar sucks. There is no apostrophe in Nazis!

Re:2038!?!!

[evil_aar0n]

You planted a logic bomb? You must be one o' them "tourists" G. Bush keeps talking about. Please report to the nearest flogging chamber for suitable punishment.

No

[Weaselmancer]

Just the Linux port of it.

Re:No

[Nazlfrag]

There's another OS that uses Unix timestamps.. by some Bill guy, I'll remember soon..

I wonder...

[phsdeadc0.de]

...if people asked similar questions in the 80s.

Re:I wonder...

[Cajun Hell]

Huh? By 2080, the problem had already been dealt with. They permanently fixed it by using the sign bit.

Incorrect....

[gweihir]

Older flavours of Unix will wrap-around on 32 bit int. More modern systems use time_t instead of int and may or may not be affected by the problem. time_t can be unsigend (which gives another 68 years) or long long int/long long unsigned (which are both 64 bit long). In any case, fixing the basis library and recompileing is enough for properly implemented software.

Re:Incorrect....

[poot_rootbeer]

In any case, fixing the basis library and recompileing is enough for properly implemented software.

Whew! It's a good thing most software is properly implemented, then.

Re:Incorrect....

[Anonymous Coward]

It's very rare for time_t to be unsigned. There are some systems where it is (IIRC, QNX is an example) but the vast majority of OSes use a signed type for time_t.

Just about any 64-bit system will have a 64-bit time_t. There are some 32-bit environments where time_t is 64-bits (FreeBSD, Windows... yes windows has time_t even though it's not the "native" time format) but many more are have a 32-bit time_t.

So I guess the question is "how long until 32-bit environments disappear completely?" From the server market they're basically gone already. Desktops/notebooks will probably be all 64-bit easily within the next 5 years. 32-bit architectures might live on in the embedded space for quite some time, however.

Re:Incorrect....

[Anonymous Coward]

time_t can be unsigend (which gives another 68 years) or long long int/long long unsigned (which are both 64 bit long). It can be, but it's not.

32-bit Linux hasn't made the switch yet.

If it's so easy to do, then do it NOW. If not, then it becomes especially important to do it NOW. The fact that 32-bit Linux hasn't done this yet is a very bad sign.

If we don't do the switch now, then when WILL we do it? Will we do it when it's "convenient"? When exactly will that be? How do you know they won't just keep putting this off until 2038?

(FYI: There's no reason to assume that we won't still be using 32-bit embedded systems in 2038. This excuse that "everything will be 64-bit in 2038" is just pure nonsense. A small minority of all processors will be 64-bit in 2038 -- simply because they won't need the extra cost nor the extra data width.)

Re:Incorrect....

[mzs]

That's interesting as mktime() returns -1 on error. I hope you have been writing something like this on all those systems:

...
t = mktime(tp);
if (t == (time_t)-1)
...

Personally I know that single pesky one based field ALWAYS screws me up. (Brain why, WHY WON'T you finally learn!?)

Re:Incorrect....

[Snorpus]

And the source code is on that 8" floppy disk in the back of Joe's filing cabinet.

I wonder if Joe took it with him when he retired?

Re:Incorrect....

[SL Baur]

Older flavours of Unix will wrap-around on 32 bit int. More modern systems use time_t instead of int and may or may not be affected by the problem. That's right and wrong. Version 7 (the oldest version of Unix I used) had time(2) returning a signed long integer. I don't think they changed that to time_t until System V. The most common Unix systems have always had a 32 bit long int.

Glibc defines time_t as a signed long integer.

If you've been a megabozo and using int for time(2) your application will lose. But if you've been a bozo and hardcoding long int, a recompile on a 64 bit platform will still fix you.

Re:Incorrect....

[gweihir]

Since software is not binary portable on these systems, if he hads not preserved the sources, it will not run in modern systems in the first place. As you would know, if you had any insight into the issue.

Re:Incorrect....

[Anonymous Coward]

You are assuming the source code is available for all of these applications, which is dubious at best.

Re:Incorrect....

[English French Man]

I'm greatly relieved to hear that. By the way, why do any date format have a limit this close in the future? We had it for two-digits year, and knowing that they design a 32-bits date format which ends near 2038...

Re:Incorrect....

[Raedwald]

time_t can be unsigend (sic)

Yes. The C standard requires that time_t is an arithmetic type (see section 7.23.1 of the C99 standard). That means it can be an integer or floating type (see section 6.2.5 of the C99 standard), and therefore could be a float, double, long double, a complex-number (WTF?), a char, a signed integer type or an unsigned integer type. The C standard requires that (time_t)(-1) is not a valid time value, so it can be used it indicate a failure (as a previous poster pointed out, this is what mktime() can do; see section 7.23.2.3 of the C99 standard).

POSIX requires that a time_t records time in seconds and must be an integer or real-floating type. POSIX also requires that the time() function return the number of seconds since the Epoch, and therefore implicitly need not be able to represent times before the Epoch, so a time_t need not be a signed type. POSIX also provides the following rationale.

Implementations in which time_t is a 32-bit signed integer (many historical implementations) fail in the year 2038. IEEE Std 1003.1-2001 does not address this problem. However, the use of the time_t type is mandated in order to ease the eventual fix.

POSIX also notes the following as a future direction.

In a future version of this volume of IEEE Std 1003.1-2001, time_t is likely to be required to be capable of representing times far in the future. Whether this will be mandated as a 64-bit type or a requirement that a specific date in the future be representable (for example, 10000 AD) is not yet determined.

Re:Incorrect....

[gweihir]

Very simple: This format was done about 35 years ago. Nobody back then could imagine that it could possibly survive more than 60 years. But it is still better than other formats, since it can be extended easily. In fact, if you do calculations beyond the +/-68 years from 1970, you already use 64 bit signed integers today or (as a workaround) the 53 bit integer precision offered by IEEE754 "double".

Re:Incorrect....

[gweihir]

Hmm. Seems unsigned is a bad idea. I saw it used somewere, but obviously not as time_t. Use 64 bit integer then instead.

Re:Incorrect....

[gweihir]

Yes, the -1 return value makes unsigned a bad choice. I swa it used somwhere, but obviouly not as time_t. I apologize. Still, this is one place were extending the time format is easy and conversion is entrirely generic. As to ccomplex, just set the imaginary part to 0 and get a perfectly good ordinary number.

Re:Incorrect....

[gweihir]

The embedded space you mention might be the real issue. Linux is in a lot of embedded things today and often the people porting it there are not really Unix people and may not have a long-term view. However I expect that in the next decade or so time_t will be made 64 bit on Linux (as 64 bit integers have been available on 32 bit systems for quite some time) and the "conversion may loose significant digits" compiler error may even get people to realize that 32 bit is not enought for time representation anymore.

Re:Incorrect....

[poot_rootbeer]

Since software is not binary portable on these systems, if he hads not preserved the sources, it will not run in modern systems in the first place

Unless the modern system is emulating a legacy system, and the binary-only software works fine within the legacy emulation.

Re:Incorrect....

[gweihir]

That is not done in the Unix world.

Not an program problem, but a file format ditto

[Anonymous Coward]

Before we get anywhere near 2038, you'll have to search a while for 32-bit hardware.
Maybe your dishwasher will have one, maybe not.

So there problem is not with programs. It is with file formats.

Several file formats, notably gzip and tar [if memory serves] contain 4-byte time
stamps. These file formats need to be upgraded well before then. Or else.

--Morten

Y2K38???

[Anonymous Coward]

How about Y2.038K instead.

And for the nitwits who think everything's okay because by Y2.038K everything will be 64-bit: banks are computing 30 mortgages today.

And BTW, banks have been computing 40 year mortgages since 1998, so maybe it's not such a big deal after all.

Re:Y2K38???

[marcansoft]

In Electrical Engineering, the multiplier is commonly used to replace the decimal point in component. For example, you could call a 4.7k resistor a "4k7" resistor, and a 2.2nF capacitor might be called a "2n2" capacitor.

That would make it Y2k038.

Re:Y2K38???

[KudyardRipling]

That may be true on the schematic (especially European equipment), but when on the circuit board, I'm looking for red, black, orange, and gray.

'Tis a bit daffy since it does not shorten the character count.

Re:Y2K38???

[marcansoft]

Don't you mean Red, Black, Orange, Gray, Black? :)

Re:Y2K38???

[KudyardRipling]

Zero tolerance. [groan]

Re:Y2K38???

[marcansoft]

No, the black is the 10^n. Though you could add another black for tolerance, although I don't think there is a standard color for "zero tolerance".

Re:Y2K38???

[KudyardRipling]

Multiplier band (smacking self in face). [groan] It's good to see that someome is mindful of discreet components in hardware.

2048

[Kifoth]

Isn't 2048 also supposed to be problematic? Binary 2047 (11111111111) into binary 2048 (100000000000) will add an extra digit.

Re:2048

[Inquisitus]

Who the hell stores years as 11-bit integers?

Re:2048

[IdleTime]

1 11 11 11 11 11 is not a real binary number, it is handled internally as at least 00 00 01 11 11 11 11 11 which will lead to no problems.

Re:2048

[Anonymous Coward]

Your mom stores years as 11-bit integers.

Re:2048

[Curien]

Not "real binary"? WTF are you talking about? It's either binary or it's not. And it's binary.

As for your poorly-made argument that computers use words with certain widths, just because you've never used a computer where CHAR_BIT != 8 doesn't mean they don't exist.

Re:2048

[Volante3192]

Well, technically it is a real binary number, as it contains only 1s and 0s. It is not, however, representative of how 2047 would be stored in a computer. That'd be the Year 65536 bug.

Re:2048

[cheater512]

No I'm pretty sure 11 bit computers are exceedingly rare and there wont be any problems because of them. :)
Hell 9 bit is more popular.

Re:2048

[Anonymous Coward]

As for your poorly-made argument that computers use words with certain widths, just because you've never used a computer where CHAR_BIT != 8 doesn't mean they don't exist. -- It's always a long day... 86400 doesn't fit into a short. I like the .sig here; ya gotta love the power of cognitive juxtaposition. :)

Re:2048

[TheThiefMaster]

It's "Number of seconds since midnight (0:00:00) January 1st 1970". Which in a SIGNED 32-bit number, overflows into negative in 2038.

If they'd used an unsigned 32-bit number, then they would have had dates up to 2106 covered. Unfortunately whoever invented these timestamps chose to make them use signed numbers, with negative numbers being allowed on some systems (representing dates before 1970) and being errors on other systems (e.g. Windows)...

Fortunately 64-bit numbers can now be handled by pcs, and can be used as an extended timestamp to get a few billion years of time. Most operating systems have already been converted, it's just legacy programs that would have issues.

Re:2048

[hsdpa]

RTFA! Unix-time is the SECONDS since Jan 1st, 1970 (not counting leap seconds). Often stored in a signed 32-bit integer, called time_t.

Re:2048

[MartyBorg]

Hey. There's only 10 kinds of people in this world: Those who understand binary ... and those who don't.

Re:2048

[robfoo]

http://xkcd.com/366/

Re:2048

[Curien]

I love it when people complain about the sig. Then I get to tell them that C guarantees that a short can store numbers between -32767 and 32767 (no, I didn't get the negative one wrong) inclusive, regardless of CHAR_BIT or the word size of the system.

Re:2048

[Anonymous Conrad]

I love it when people complain about the sig. Then I get to tell them that C guarantees that a short can store numbers between -32767 and 32767 (no, I didn't get the negative one wrong) inclusive, regardless of CHAR_BIT or the word size of the system. A short can store *at least* the range -32767 to 32767: C99 5.2.4.2.1 says

Their [SHRT_MIN and SHRT_MAX] implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign.

In other words it's perfectly legal C to define short to be 18-bits, say, and then I can have all the "short" days I want.

Re:2048

[eu4ik]

I want an Ironic modifier! Your sig ("It's always a long day... 86400 doesn't fit into a short.") might not be true on one of those same unusual architectures!

Re:2048

[megaditto]

Fortunately 64-bit numbers can now be handled by pcs Is this one of those "old timer" jokes about a steam-powered computers with 63 bits of RAM?

Re:2048

[stonecypher]

Epoch is seconds since Jan 1, 1970. That's why it's 2038, not 2048. Go on, you know you want to count out 32 bits of seconds.

Re:2048

[stonecypher]

Unfortunately whoever invented these timestamps chose to make them use signed numbers, with negative numbers being allowed on some systems (representing dates before 1970) and being errors on other systems (e.g. Windows)...

Whoever invented these timestamps did so before Microsoft was formed. According to The History of Computing Project, the earliest known reference to Microsoft is an announcement of the partnership as Micro-Soft in a Nov 29 1975 personal letter. The UNIX time date stamping system was in use in V1 in 1971 (though not in UNICS). I have it on suspicious authority that the mechanism may be inherited from a Multics mechanism with a different epoch date, but I cannot find proof.

It's got less than nothing to do with Windows, and it's not about system compatibility. The choice of a signed number was simple: at the time, timespans were encoded as negative numbers. That was removed by v2 because it caused a lot of problems in naively written code. You're presenting guesswork as fact: that's a particularly pernicious form of lying, because other people start to repeat it, thinking it's true. Quit being such a kneejerk jerk. You have no idea what you're talking about.

Fortunately 64-bit numbers can now be handled by pcs

Mechanisms for handling 64 bit numbers have been in every edition of UNIX sold or distributed for more than 20 years, since the POSIX consortium was called in 1985 to standardize the existing differing mechanisms between Ultrix, SunOS, MIPS/BSD/Mach, V8, Xenix and so on. Stop making things up to seem smart.

Whoever marked that informative should contact me for bill of sale in re: Brooklyn Bridge.

Re:2048

[onemorechip]

Perhaps he means one of the 1s is used to represent the square root of -1. Maybe in some weird notation used for complex arithmetic.

Re:2048

[jmac1492]

Not "real binary"? WTF are you talking about? It's either binary or it's not. I propose we use the value 1 to represent binary, and the value 0 to represent not.

Re:2048

[Anonymous Coward]

11 digits, anyways.

Re:2048

[TheThiefMaster]

Well obviously the timestamp was invented before Microsoft supported it, isn't that the case with everything?
But still, officially, are negative timestamps supposed to be valid or not? I honestly don't know, I just know that they work in some implementations and indicate errors in others.

The 64-bit numbers thing was more referring to native cpu support, of course by writing a little clever code you can handle numbers as large as you want. It was also a jab at anyone using the 32-bit versions, given how long the 64-bit versions have been available.

Re:2048

[Anonymous Coward]

so... just out of sheer curiosity, why couldnt they change the reference from "Number of seconds since midnight (0:00:00) January 1st 1970" to "Number of seconds since midnight (0:00:00) January 1st 2000"

Not the best fix, but it would (theoretically) give us 30 more years to fix the problem, or develop new solutions, or become extinct...

Re:2048

[dargaud]

Fortunately 64-bit numbers can now be handled by pcs [...] Most operating systems have already been converted Bzzzt, wrong. It's a problem above all at the programming language level, for instance even C standard 99 keeps time_t explicitely as a 32-bit integer. The problem is cluless programmers saving this time_t into file fields, making the transformation to a 64-bit field nearly impossible. C and other languages need to add a time_t64 quickly so that we programmers can at least start the transition.

Re:2048

[TheThiefMaster]

Yup, it's the same issue as programmers who saved pointers into 32-bit numbers, instead of storing them in, I don't know, a pointer; whose programs will probably compile (with warnings) but will crash horribly in a 64-bit version.

Also, most C libraries do have a time_64_t (or whatever its called) and most operating systems HAVE already been fixed to avoid this Y2038 bug. It's just software that still has problems.

Re:2048

[Curien]

A strictly-conforming program may only store values between -32767 and 32767 (inclusive) in an object of type short, regardless of the machine architecture.

Re:2048

[Curien]

"Legal" is not a C concept. A strictly conforming program "shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit."

A "correct" program may rely on implementation-defined (and even unspecified) behavior. Since use of those behaviors necessitates qualification, lack thereof (such as in my sig) implies strict conformance.

Basically, as I mentioned somewhere else, the sig as written sounds a lot better than something along the lines of, "A strictly conforming C program may not rely on storing the value 86400 into an object of type short to result in well-defined behavior."

Re:2048

[petermgreen]

Isn't 2048 also supposed to be problematic? Binary 2047 (11111111111) into binary 2048 (100000000000) will add an extra digit.
probablly problematic for some obscure systems that store the complete year number in a 11 bit number (or more likely a 12 bit signed number).

The fact is there are all sorts of rare date stamp systems that run into issues at a particular date. Systems will either be fixed or decomissioned in the runup to whatever thier particular cutoff date is hopefully without too much trouble and for most formats it will only be a few systems failing at a time.

However some issues are so common that they will cause problems to hit with a lot of systems at the same time. Some of the key ones are:

* year in two decimal digits, Y2K should have taught us our lesson on this one but now it's passed I bet a lot of new system designers are thinking thier systems won't be arround in 2100 ;).
* leap year rules, the gregorian rule is a year is a leap year if (((y%4)==0)&& !((y%100)==0))) || ((y%400)=0) but many use the rule (Y%4)==0 which is correct for 397 out of 400 years. Again this problem hits in 2100.
* dos datestamps. Theese will overflow in (finding any information on the format at all seems to be a PITA) 2108 (though some implementations that use signed 16 bit variables may have trouble with ones beyond 2044). Dos dates are used in the common fat filesystem and the common zip archive format.
* unix date/time stamps stored in 32 bits. Theese will overflow in 2038 if signed and 2106 if unsigned. (yes 64 bit ones will eventually oveflow too but I doubt humans will be arround in a recognisable form when it does.

Re:2048

[Gazzonyx]

Unfortunately, these legacy programs are the ones that are too complex and embedded in to their little niche, to allow an easy change.

Banks will use software until the bits rot; a local bank (PA, USA) that is relatively large, still hires people that know COBOL because it's what their software interfaces their database with. Companies in this category are probably going to have an easier time scrapping their code and rewriting than trying to change to 64 bit time. I've heard the same about electric companies.

Re:2048

[petermgreen]

C standard 99 keeps time_t explicitely as a 32-bit integer
hmm the closest thing I can find to the C99 standard online without paying (a draft version of a version with some minor ammendments added) says

"The range and precision of times representable in clock_t and time_t are
implementation-defined."

Checking things quickly on amd64 linux time_t is 64 bit, on i386 linux it is 32 bit.

The problem is changing the size of a standard type like time_t breaks the platforms C abi, the glibc maintainers understanablly don't want to go through a C abi change for an issue that won't affect anything for three decades to come. Also some file formats almost certainly have a fixed 32 bit space for a timestamp.

Re:2048

[eu4ik]

Really? Reference please. I'll admit I haven't read the C language standard in years, but the only guarantee I recall is that sizeof short = sizeof int = sizeof long. From the wikipedia entry (hardly authoritative, but I'm too lazy to search for anything better): "It is perfectly valid, for example, that all four types be 64 bits long."

Re:2048

[Curien]

I'm not sure, but I'm guessing you had angle brackets in there:
sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long).

In addition, there are certain minimum ranges for values of each type. char must be at least 8 bits (CHAR_BIT must be at least 8), short and int must be at least 16 bits, long at least 32, and long long at least 64.

I don't own a copy of the standard, but from the draft:

[A strictly conforming program] shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.

and

Their implementation-defined values shall be equal or greater in magnitude (absolute value) to those shown, with the same sign. ...
-- minimum value for an object of type short int
                        SHRT_MIN -32767 // -(2^15-1)

-- maximum value for an object of type short int
                        SHRT_MAX +32767 // 2^15-1

Since trying to store a value outside the minimum range for a short would rely on implementation-defined behavior, a program which attempts to do so is not strictly conforming.

Re:2048

[mwarnock]

Your assumption that it's either binary or not is a binary assumption.

In an analog world, it can vary between "binary" and "not binary", so it could be "almost completely binary", "almost completely analog", or anywhere in between.

Analogously (ahem), There are two kinds of people in the world-- people that divide people into two kinds (binary people), and people who don't (analog).

Re:2048

[geminidomino]

Well obviously the timestamp was invented before Microsoft supported it, isn't that the case with everything? Yes, but microsoft were truly pioneers of memory management! Who else would have thought to store system uptime in a byte?

Don't forget embedded!

[EmbeddedJanitor]

There were approx 200 million PCs sold in 2007 and 4 billion embedded systems (1:20). Most embedded systems are still using 8-bit CPUs. A 64-bit world is still a long way off.

Re:Don't forget embedded!

[Zadaz]

Yeah. And we all know you can't use numbers bigger than 8-bits on a 8-bit CPU.

What. What? And this got moded "Informative"??

Re:Don't forget embedded!

[Anonymous Coward]

Yeah. And we all know you can't use numbers bigger than 8-bits on a 8-bit CPU. What. What? And this got moded "Informative"??

Well, it's at least as informative as the post it responds to was. And as a matter of fact, the GP is correct, and furthermore, neither claims nor infers that this is an inherent problem of simpler processors. It's just that there's a lot more embedded systems in that this may need to be addressed in than there are PC's.

They both miss the target a little bit since it's the size of the timestamp, not the processor bits, that is the problem.

Re:Don't forget embedded!

[nsayer]

I suspect the substantial majority of those embedded systems not only aren't running POSIX, making Y2038 irrelevant for them, a substantial number of them probably don't have clocks, much less calendars.

As for the 200 million PCs sold in 2007, I rather suspect that a substantial majority of THOSE were probably equipped with modern Core or AMD CPUs with X86-64, making it possible for them to run 64 bit operating systems.

But in any event, the suggestion that a 64 bit operating system is required to correctly deal with a time_t is obviously ludicrous.

Re:Don't forget embedded!

[Nimey]

How many embedded 8-bit microprocessors are hosting a Unix with a 32-bit time_t?

Thought so.

Re:Don't forget embedded!

[EkriirkE]

By that logic, computers were doomed to negate by January 1, 1970 00:00:02 However, if they had used signed 8-bit time, they could have saved the computer industry until a whole lot of worry until January 1, 1970 00:00:04

Re:Don't forget embedded!

[gr8scot]

It would be the reader who "infers". You meant to say "the GP ... neither claims nor implies that this is an inherent problem of simpler processors."

You're welcome.

Re:Don't forget embedded!

[Alioth]

The vast majority of embedded systems don't care about the time, either.

On a point of pedantry, it's also a 31 bit overflow given that time_t is signed. (If it were a 32 bit overflow, we'd have a considerably longer period before having to worry about it).

That's nice.

[riseoftheindividual]

I didn't say there was.

Roll-yer-own date calcs are easy

[EmbeddedJanitor]

There are many. eg: http://en.wikipedia.org/wiki/Zeller's_congruence

You are not bound to use Unix dates within the program.

Many finance houses are happily dealing with dates maturing well after 2038 (eg. 50 year loans, retirement plans for 25 year olds etc).

I don't give a shit

[Anonymous Coward]

I don't give a shit. And I mean that in the most literal, non-idiomatic way. If I had a pile of turds in my back yard, and you were to walk up to me and say, "Excuse me, sir, if you would let me relieve you of one of these useless pieces of feces I could guarantee a resolution to the Y2K38 computer issue," I would simply reply, "I'm sorry, but those are my shits, and I'm not giving one."

Re:I don't give a shit

[Karem Lore]

Can't you just produce another one?

Re:I don't give a shit

[Jeng]

Now why did you waste a wonderful comment like that by posting as AC?

Re:I don't give a shit

[Chris Burke]

I don't give a shit. And I mean that in the most literal, non-idiomatic way. If I had a pile of turds in my back yard, and you were to walk up to me and say, "Excuse me, sir, if you would let me relieve you of one of these useless pieces of feces I could guarantee a resolution to the Y2K38 computer issue," I would simply reply, "I'm sorry, but those are my shits, and I'm not giving one."

You are clearly a person who has their shit together.

Re:I don't give a shit

[Anonymous Coward]

http://www.bannination.com/comments/5021791

Re:I don't give a shit

[ruiner13]

No shit?

Re:I don't give a shit

[ookabooka]

I don't give a shit. And I mean that in the most literal, non-idiomatic way. If I had a pile of turds in my back yard, and you were to walk up to me and say, "Excuse me, sir, if you would let me relieve you of one of these useless pieces of feces I could guarantee a resolution to the Y2K38 computer issue," I would simply reply, "I'm sorry, but those are my shits, and I'm not giving one."

You are clearly a person who has their shit together.

Yes, and prior to his mass defecation in his own back yard he must have been quite full of shit.

Re:I don't give a shit

[TheQuantumShift]

And always has an answer for Bruce Willis when he asks,

"Where's the shit?"

hmmmm

[DCTooTall]

So are we saying that the fact that all these loan companies are failing or are in trouble now is because of a software bug and not because people can't pay their bills?

Re:hmmmm

[jmauro]

No. It's due to an unrelated bug in the printing subsystem. Nice guess though.

Need to fix it now!

[Anonymous Coward]

This needs to be fixed now. Embedded systems can have a long lifetime (think building thermostats, alarm systems, industrial control systems and other infrastructure). The Y2K problem was a tremendous failure of the engineering and computing professions to react to a known problem. The Unix/Linux world should not repeat that mistake.

Re:Need to fix it now!

[SL Baur]

This needs to be fixed now. Embedded systems can have a long lifetime (think building thermostats, alarm systems, industrial control systems and other infrastructure). It's been fixed. Recompile with 64-bit userland and a 64-bit kernel. Coding changes now won't solve anything on existing embedded systems and for near future embedded systems where speed and space is of utmost concern, it makes sense to keep it 32-bit for as long as you can.

Code speaks louder than words, look:
$ grep 64.*time_t asm-x86/**/*.h
asm-x86/msgbuf.h: * - 64-bit time_t to solve y2038 problem
asm-x86/sembuf.h: * - 64-bit time_t to solve y2038 problem
asm-x86/shmbuf.h: * - 64-bit time_t to solve y2038 problem

The context is:
  * Pad space on i386 is left for:
  * - 64-bit time_t to solve y2038 problem
  * - 2 miscellaneous 32-bit values

What's the prevalence of use?

[wytcld]

Most often when I've set up date fields in databases, I've used the YYYYMMDD format (e.g. 20080115, YYMMDDHHMMSS of course is also an option). The simple regex to construct it and read it is barely more code than translating in and out of Unix timestamps, and there's the great advantage that the dates are human-readable in the tables, and ad hoc queries are easily constructed. So I should be good until the year 10,000. Am I the only one? It's always seemed the obvious best way to do it.

Re:What's the prevalence of use?

[Shados]

Don't know about others but me I just use a DateTime field and stick a date object in it, and let the drivers handle the conversation... Now -that- to be seems the obvious best way to do it... Why convert at all, unless someone's using an archaic and incomplete RDBMS.

Re:What's the prevalence of use?

[Just Some Guy]

I've used the YYYYMMDD format (e.g. 20080115, YYMMDDHHMMSS of course is also an option). The simple regex to construct it and read it is barely more code than translating in and out of Unix timestamps

You use Perl, don't you.

Re:What's the prevalence of use?

[Anonymous Coward]

Why convert at all, unless someone's using an archaic and incomplete RDBMS.

Something like MySQL which lets you store impossible dates in a date field?

Re:What's the prevalence of use?

[aj50]

Or combining MySQL and Access and being unsure whether each will produce or expect a US style date or a UK style date or a MySQL style date. In the end I wrote code to make Access Dates from MySQL Dates and vice-versa.

Re:What's the prevalence of use?

[eison]

Most people don't do this because performance for "show me everything in the past 7 days" style queries sucks this way. You have to do a lot of like based substring compares, which aren't indexed, so full table scans.

Re:What's the prevalence of use?

[Joe Mucchiello]

Performance? It's just 8-byte string comparisons.

SELECT * FROM wherever WHERE mydatefield between '20080110' and '20080116'

YYYYMMDD is sortable by day so you just construct the string version of 7 days ago and off you go. Why would I do substring scans?

How about the third quarter results?

SELECT MAX(money) FROM accounts WHERE datefield between '20070701' and '20070930'

No, the only real problem with using this method is bogus dates: 20089321. There's nothing to prevent them.

Re:What's the prevalence of use?

[KZigurs]

never used date_trunc(or _part) and group by, haven't you?

Re:current debts unrepayable

[Anonymous Coward]

Please don't breed.

It's a non issue.

[Higaran]

The mayan calendar ends in 2011 or 2012, I cant remember off the top of my head, so thats supposed to be the end of the world from what conspiary theoriests say, so that means the world will end 20+ years before this ever happens, so who cares ;)

Re:It's a non issue.

[Anonymous Coward]

It ends in 2012. It also says in the Bible something like 'the history of the world will be divided into 12 periods and the 11th is half over.' That was in the Torah so we must be into the 12th period by now.

Re:It's a non issue.

[matrixghost1286]

According to the History Channel Doomsday specials,
the Mayan calendar shows the end of the Earth to occur on December 21, 2012.
In the show, pets go nuts and attack their owners. Computers and home appliances began to attack;
an iron "presses" someone, a toaster eats a hand, and a guy was killed by all of the home office equipment.
But the best part was the Christmas Tree (or Holiday Tree) which comes to life and attacks.

Re:It's a non issue.

[Jehosephat2k]

Here you go watch the video: http://www.december212012.com/articles/mayan/index.shtml

Also you can buy tee-shirts and dongles.

Re:It's a non issue.

[Anonymous Coward]

Funny. They could predict the end of the world, but they couldn't predict their own demise. Yeah, it sounds like we should put a lot of stock in their crappy calendar...

Why is this a problem?

[zippthorne]

This is nothing like the two-digit date problem of Y2K. The conversion process shouldn't be anywhere near as complicated, since 32bit dates are just an arbitrary subset of a larger bit-count dates. There are really only two cases, signed and unsigned, and casting things into larger containers isn't exactly all that difficult: if unsigned, stick a bunch of zeros on the front. If signed, stick a bunch of zeros on the front, then swap the previous MSB with the new MSB.

Furthermore, C programmers haven't exactly become a rare commodity in the intervening time like with COBOL. Y2K wasn't a problem, so why should we expect Y2K+38 to be a problem?

Re:Why is this a problem?

[DerekLyons]

Y2K wasn't a problem, so why should we expect Y2K+38 to be a problem?

Y2K may not have been a problem for you - but your experience is not universal.

Re:Why is this a problem?

[Chris Burke]

if unsigned, stick a bunch of zeros on the front. If signed, stick a bunch of zeros on the front, then swap the previous MSB with the new MSB.

Assuming twos-complement signed integers (a safe assumption if using Unix time), I'd think you'd be better off sign-extending (duplicating the old MSB into all upper bits) rather than zero-extending and swapping msbs.

E.g. going from 4 to 8 bits:
1010 = -2
11111010 = -2
10000010 = -126

Anyway, that's all taken care of under the hood in C when you copy a 32-bit signed source to a 64-bit signed destination, and yeah all the C programmers still around should be able to handle the problem admirably. The biggest problem will just be identifying all the places where 32-bit times are stored in files and other places where it isn't as simple as just re-compiling the code to use a 64-bit integer for time (which is already the default on 64-bit systems, time_t is 64 bits).

Re:Why is this a problem?

[Chris Burke]

1010 = -2
11111010 = -2

Haha, screwed that up, that's -6, not -2.

Re:Why is this a problem?

[serialdogma]

It's not his fault, he was using an Pentium.

Of course they did.

[Eevee]

I can remember coming across a book about the entire Y2K thing back in the late '70s, filled with both dire warnings and algorithms. And I remember thinking, "Jeez, that's over 20 years away. Nobody's going to be using any software around today that far in the future."

Re:Of course they did.

[KillerBob]

I can remember coming across a book about the entire Y2K thing back in the late '70s, filled with both dire warnings and algorithms. And I remember thinking, "Jeez, that's over 20 years away. Nobody's going to be using any software around today that far in the future."

My dad was actually hired by the Bank of Canada in the early 1970's to update their software to be Y2K compliant....

So yes... they were well aware of it back then. Likewise, they've been aware of the 32-bit Unix time expiry since they introduced Unix time. I'd be surprised if they weren't already working on a solution. Actually... I'd be surprised if they hadn't already implemented a solution to it.

Pure alarmism. Just like we had in 1999.

Re:Of course they did.

[sjames]

What I thought was funny about Y2K was after all the fear over old COBOL programs, the reletively new perl scripts were the problem.

are you like those Moscone Center ridiots?

[peter303]

People lining up all night to get into Job's keynote address?
Some people worry too much.

your payments will be $1453 a month...

[swschrad]

EXCEPT for january 2038, when you have a payment of $126,347,883.39 and escrow due of $998,554,073.18.

please make a note for your records.

thank you.

FOSS Mortgage Co.

What about the new 40 and 50 year loans?

[mikehoskins]

What about the new 40 and 50 year loans?

Sooooo, isn't this, thus a non-issue, like Y2.000K?

Re:What about the new 40 and 50 year loans?

[kcornia]

40 and 50 year loans are really 30 year loans that will be refactored (or rewritten or reset, whatever terminology they used) at 10 and 20 years left respectively. From my recollection based on work in subprime IT for a few years, it has to do with laws that limit the life of a loan to 30 years or something.

Regardless, 40 and 50 year loans are right up there with negative amortization adjustable loans. HORRIBLE ABUSE OF TEH SYSTEM. If you have to stretch that far to get into a house, rent a fucking apartment and save up some money for cryin' out loud.

This credit crunch is a good thing, we as consumers need to get off the endless debt teat.

Re:What about the new 40 and 50 year loans?

[Erik Hensema]

Y2K was mosty (!!) a non-issue because we saw the problem coming and fixed it.

Re:What about the new 40 and 50 year loans?

[jandrese]

That and most of the Y2K problems were just display errors, not bugs in the actual calculations going on under the scenes. 2038 is much scarier and is a lot more difficult to fix. In fact the best way to fix the problem is probably to switch to a 64 bit representation of time, but thus far not too many people have made moves in that direction. Switching to 64 bits is not as easy as it might sound either, since lots of programs use timestamps and many of them make assumptions as to the size of their time fields. I do wish APIs would start to get transition structures (time_t64 or something) in place that people could start using now. If you do it early enough you can save yourself a lot of headaches down the road.

The big problem of course is that most people figure their code won't be in use in 2038 and don't care. I'll be right about retirement age by then. Crap, I just realized I'm going to be the grizzled old guy they call when this problem finally rolls around. One of those crusty old farts that knows C (just like the crusty COBOL farts that got a lot of jobs back in 1999 for a few months).

Re:What about the new 40 and 50 year loans?

[Lost Engineer]

Dude you can rent an apartment in Houston for 400 bucks a month. What are you on, social security?

Re:What about the new 40 and 50 year loans?

[p0tat03]

Another problem is that we will still see lots of 32-bit CPUs in all manners of devices come 2038... I don't think 32-bit will simply drop off the map like that. In that case, even if we STORE dates in 64-bit format, doing any sort of numeric manipulation thereof will be somewhat more complicated.

Re:What about the new 40 and 50 year loans?

[Anonymous Coward]

64-bit time_t on sparc64(freebsd sparc64 list feb/2004)

The open tools&OSes are making their way towards 64-bit time_t; some already have it.

Re:What about the new 40 and 50 year loans?

[who'sthat]

Crap. I worked on y2k stuff and the problems were data storage problems and variable size. Only 1st 2 digits stored in the data and calculations assumed that only the 20th century existed.

Re:What about the new 40 and 50 year loans?

[gronofer]

What about the new 40 and 50 year loans?

It's not necessary to calculate any loans out to 2038, since they will probably be written off before the end of 2008.

Re:What about the new 40 and 50 year loans?

[Colin Smith]

This credit crunch is a good thing, we as consumers need to get off the endless debt teat. Sorry. You Can't...

Re:What about the new 40 and 50 year loans?

[Hognoxious]

TFA mentions problems with loans where the end date falls after rollover day. I think it's pretty unlikely that financial software uses a time_t variable for its calculations. It's much more fine grained than you'd need for that purpose.

Re:What about the new 40 and 50 year loans?

[Richard W.M. Jones]

TFA mentions problems with loans where the end date falls after rollover day. I think it's pretty unlikely that financial software uses a time_t variable for its calculations.

Heh, you'd be surprised ...

Rich.

Re:What about the new 40 and 50 year loans?

[ibwolf]

Regardless, 40 and 50 <snip> If you have to stretch that far to get into a house, rent a fucking apartment and save up some money for cryin' out loud.

While it is certainly prudent to consider all your options in some cases (such as mine) a long term loan may work out as the best option.

My current loan has 40 year term. I did look into the numbers quite a bit and decided that a shorter term loan would squeeze my monthly budget unnecessarily. Renting a comparable apartment would have been even more expensive (I did have considerable equity so the loan only needed to cover about 65% of the purchase price). I guess I could have tried for something cheaper but that would have meant either a substantially inferior apartment or at least an additional hour/hour and a half commute plus living further from family and friends. Most likely both.

All the numbers simply added up to the 40 year loan making sense.

Re:What about the new 40 and 50 year loans?

[Anonymous Coward]

Really? Thats, what - about £200? I must get one.

And the commute to work would only be about eight hours or so.

And no, I'm not claiming Jobseekers Allowance. What makes you ask?

Re:What about the new 40 and 50 year loans?

[Hognoxious]

I should have explicitly stated that I meant software written by sane people. Are you a WTF reader, perchance?

Re:What about the new 40 and 50 year loans?

[Richard W.M. Jones]

Right, sane people :-)

Re:What about the new 40 and 50 year loans?

[Net_Wakker]

thank you. that was a most informative link.

Here we go again, year2038.pl

[quarkie68]

#!/usr/bin/perl
# (or wherever your camel lives)
#Copyleft (just joking!) Georgie http://folk.uio.no/georgios
use POSIX;
use strict;

$ENV{'TZ'} = "GMT";
# GMT for preference
print "And the transition will be like...\n";
for (my $clock = 2147483646; $clock < 2147483650; $clock++)
{
    print ctime($clock);
}

chomp(my $conclusion=ctime(2147483650));
if ( $conclusion=~ /1901$/) {
        print "Which means that you are bugged by 32 bits. We have 64 bit processors and structures now you know!\n";} else {
        print "You will survive for now. Go and get a beer. \n";}

Re:Here we go again, year2038.pl

[Quietust]

Amusingly, that script improperly predicts survival on Windows when running it in ActivePerl 5.8.8, where ctime() returns an empty string if the date is greater than 2147483647 and thus doesn't see "1901".

Re:Here we go again, year2038.pl

[guruevi]

There seems to be an error in your perl script:

And the transition will be like...
Tue Jan 19 03:14:06 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038
Tue Jan 19 03:14:07 2038

Note that my clock will apparently just keep on ticking the same time.

Re:Here we go again, year2038.pl

[quarkie68]

Hi folks, I wrote this for fun on x86 and x86_64 Linux only. Not for Windows or other platforms. I suspect my choice of the ctime function or the way I try to set the timezone might be upsetting Activestate Perl/Windows, (in case the second poster ran it also on Windows). Will take a look tomorrow... :-)

Re:Here we go again, year2038.pl

[guruevi]

I ran it on PowerPC Linux and Mac OS X you insensitive clod.

Perl on Windows *shudder*, Windows *shudder*

The Binary Millenium

[stevegee58]

And let's not forget the Binary Millenium, 2048. No wonder the year 1024 was smack dab in the middle of the dark ages. It wasn't the fall of Rome, it was the first Binary Millenium!

Re:The Binary Millenium

[corsec67]

yeah, Y2K.

Although that should be: Y2Ki.

...and requires accuracy to the nearest second?

[Quadraginta]

It's a dumfuk comment in the summary. If you're calculating payments on a thirty-year loan, you sure as heck don't convert all your dates to seconds since the epoch ("Unix time"). What would be the point? You don't compound your interest by the second, and if a payment is due on such-and-such a date, you don't specify the exact second it's due.

I expect loan software converts dates and lengths of time if at all to months, that being the typical interval when you compound interest. So even on 32-bit Unix you're not going to have trouble until your loan period exceeds 4294967295 months.

Re:...and requires accuracy to the nearest second?

[mikael_j]

I actually think it's likely that something like say, the dates that various payments should be made or the date at which the loan is to be fully paid are stored down to the second. When I did tech support everything in our customer database was accurate down to one second even if there was no reason for it to be. Things like the due date on bills was midnight on the last of the month even though it would be perfectly sufficient to do those things by days, tech support calls accurate down to the minute and so on...

/Mikael

Re:...and requires accuracy to the nearest second?

[Jherico]

Whatever possible savings you might gain from writing a special representation of dates for loan calculations is going to be greatly offset by the extra QA time, bug fixing and so on. No programmer worth his salt is going to invent a new binary time representation just because the timestamps in question have a resolution of days, hours, years, whatever. They're going to stick it in the universal time type and be done with it. Even if they're using some higher level structure like a date class, internally that class is going to use the lowest common denominator of time storage mechanisms, which is time_t.

Besides, date manipulation is a mind-boggling nest of special case rules and only some sort of fetishist is going to try to write a new date representation if he doesn't have to.

Re:...and requires accuracy to the nearest second?

[Quadraginta]

I doubt it. The QA bug fixing et cetera involved in figuring out how to convert from number of months to years (hint: divide by 12, inasmuch as there's no such thing as "leap months") is going to be dwarfed by any number of other difficulties in making sure your financial software works and (more relevant) can't be diddled by idiots at the other end of the GUI.

I suspect anyone writing a loan software program is just going to do all the calculations in months, with months an integer, and then, if necessary, convert month #X to a calendar month by adding X to the month and year of the start date of the loan. As mentioned, since a year always equals a duodecimonth, exactly, this conversion is trivial. Your mind-boggling nest of special case rules only occurs when you need things like the date of the month or the day of the week. Months and years are perfectly regular.

Re:...and requires accuracy to the nearest second?

[Splab]

A good rule of thumb is to always store more data than normally needed, hence the seconds, its cheap to put it in and very expensive to recover(impossible since its lost data) if you throw the information away and suddenly need it.

Of course that means you have to think ahead and make sure you don't get hit by silly stuff like running out of bits for a date.

Re:...and requires accuracy to the nearest second?

[dan the person]

For starters, interest is often calculated daily instead of monthly.

No, the answer is not to use "int" for time

[Schraegstrichpunkt]

By 2038, no major consumer cpu manufacturer will be producing anything but 64 bit chips.

I noticed that you were careful to refer specifically to "consumer" CPU manufacturers. However, 8-bit, 16-bit, and 32-bit CPUs are still in widespread use in both consumer and industrial (embedded) electronics, and there's no reason to expect that electronics manufacturers will start using 64-bit processors exclusively, when 32 (or-fewer) bits-per-word will suffice.

Prof. Daniel Bernstein came up with a decent integer time representation called TAI64, and a public-domain library for using this representation. Using it requires getting over one's dislike of his personality, but would mostly solve the 2038 problem long before the year 2038 hits.

UTS (Amdahl's SVR3 and SVR3 implemtations) also.

[Ungrounded Lightning]

VMS has been Y10K-compliant for over a decade.

As have Amdahl's UTS operating systems (SVR3 and SVR4 for mainframes).

Whew! Good thing everyone uses Windows!

[davido42]

Why would anyone be using an OS written for scientists? They're all weird and stuff.

Signed 12-bit

[tepples]

No I'm pretty sure 11 bit computers are exceedingly rare and there wont be any problems because of them. :) Some PDP minicomputers by Digital were 12-bit. A 12-bit signed integer data type can represent whole numbers from -2048 to 2047.

Re:Signed 12-bit

[Larry Lightbulb]

12 bits? Ha. I used to work with 18 bits - http://www.bcl-computers.org.uk/molecular.htm

NO number is considered

[geekoid]

'uninteresting' FOr if it were, it would be 'interesting'.

definition of irony

[DreadSpoon]

It's either binary or it's not.

So you're saying you can't have .25 (somewhat) binary nor .84 (mostly) binary, just 0 (not at all) binary or 1 (completely) binary?

Re:definition of irony

[Anonymous Coward]

Basically he's saying that binary is boolean.

Re:definition of irony

[phoenixwade]

It's either binary or it's not. So you're saying you can't have .25 (somewhat) binary nor .84 (mostly) binary, just 0 (not at all) binary or 1 (completely) binary? heh.....
There is either an intentional whoosh here or there is not.

Re:definition of irony

[xZgf6xHx2uhoAj9D]

Boolean does not mean "true or false". Boolean means any group which satisfies the boolean axioms. The real numbers between 0.0 and 1.0 are, in fact, very common boolean types. Typically the boolean operators are implemented as:

• x AND y = xy (multiplication)
• x OR y = x + y - xy
• NOT x = 1.0 - x

Sorry, but it's just kind of a pet peeve of mine when people use "boolean" as a synonym for "true or false". Have none of you taken a course on boolean algebra?

Re:definition of irony

[Curien]

Sounds neat. De Morgan's law holds. But I'm not sure about another one (not sure of its name, but I call it the Boolean distributive property).

x ^ (y v z) = (x ^ y) v (x ^ z)

OK, so
    y v z = y + z - yz
    x ^ y = xy
    x ^ z = xz
    x ^ (y v z) = x(y v z) = x(y + z - yz)
    (x ^ y) v (x ^ z) = (x ^ y) + (x ^ z) - (x ^ y)(x ^ z) = xy + xz - (xy)(xz)

So in order for the Boolean distributive property to hold, the algebraic equation
    x(y + z - yz) = xy + xz - (xy)(xz)
must hold as well. It trivially holds if x = 0; in cases where x =/= 0, we can divide through by x to simplify:
    y + z - yz = y + z - xyz
which does not hold when x =/= 1. Therefore, we can conclude that your definitions of the Boolean operators do not generally satisfy, or I made a mistake. If I made a mistake, please point it out to me.

Even more significant dates

[spydink]

2038 is just the tip of the iceberg!!!

Significant dates

Re:Even more significant dates

[Psychotic_Wrath]

2038 is just the tip of the iceberg!!! Microsoft is going down 29602-01-01 Tue - Microsoft Windows NT file system (NTFS) fails

I resemble that

[JeanBaptiste]

I was an over-priced consultant in the Y2K bug era and it was definitely a resounding success because nothing happened, due to the hard work of an assload of people.

Re:I resemble that

[timmarhy]

while i have no doubt there were computer systems that would have had issues, the whole thing was over blown beyond all sanity. I have a toaster at home with a y2k compliant sticker

Re:I resemble that

[jamesh]

A good thing too. If just one of us had dropped the ball, that one system would have infected all the others and all electronic devices in the world would have started attacking us. All of the best and greatest people in the world would have been loaded into one rocket, the rest of us would have had to share a rocket with Pauly Shore, and would have found out too late that the it was actually heading for the sun.

I assume most of you saw that Simpsons documentry?

Re:I resemble that

[Chris Burke]

Yeah, that's what's doubly so infuriating about Y2K.

They over-hyped it to such a ridiculous degree -- not just the dangers of the bug, but that we were woefully unprepared -- that if you payed any attention to the news you expected planes to start falling out of the sky, power plants to go melt down and explode even if they weren't nuclear, and cats to mate with dogs.

When Y2K passed and their TV broadcast didn't so much as flicker, everyone correctly realized that all the hype was utter BS, and then jumped to the understandable but utterly wrong conclusion that there was never any issue at all, and it was just a scam made up by old programmers.

The truth was in the middle -- where it really, really mattered people already had their shit together, where it mattered a lot but wasn't life or death (or financial institution amounts of money) people busted ass to get their shit together in time, and where it didn't matter it didn't matter.

Re:I resemble that

[kurzweilfreak]

I was an over-priced consultant in the Y2K bug era and it was definitely a resounding success because nothing happened, due to the hard work of an assload of people,you insensitive clod!

Fixed that for you... ;)

Re:2038

[dhanson865]

Nobody stores years as 11 bit integers. Would you care to share the goofy math that made you pick 11bit instead of 32bit?

The year 2038 problem (also known as "Unix Millennium bug", "Y2K38," "Y2K+38," or "Y2.038K" by analogy to the Y2K problem) may cause some computer software to fail before or in the year 2038. The problem affects Unix-like operating systems, which represents system time as the number of seconds (ignoring leap seconds) since January 1, 1970. This representation also affects software written for most other operating systems because of the broad deployment of C. On most 32-bit systems, the time_t data type used to store this second count is a signed 32-bit integer. The latest time that can be represented in this format, following the POSIX standard, is 03:14:07 UTC on Tuesday, January 19, 2038. Times beyond this moment will "wrap around" and be represented internally as a negative number, and cause programs to fail, since they will see these times not as being in 2038 but rather in 1970. Erroneous calculations and decisions may therefore result.

ICU Universal Time Scale

[molo]

Just in time. I just happened to be looking at the ICU spec the other day, and saw that they have a pretty cool time format, the ICU Universal Time Scale. It is a 64-bit integer counting ticks of 100 nanoseconds, with an Epoch of January 1, year 1 AD. This allows dates from 29227 BC to 29227 AD.

Good stuff.

-molo

Re:ICU Universal Time Scale

[dokebi]

I think 128-bit time format, 64 for integer and 64 for fraction, is better. From wikipedia: "The 64 bit value for the fraction is enough to resolve the amount of time it takes a photon to pass an electron at the speed of light. The 64 bit second value is enough to provide unambiguous time representation until the universe goes dim."[1] Indeed, 2^64 seconds is about 54 zeptoseconds, and 2^64 seconds is about 585 billion years.

BULL

[rocketnerd112]

Im a total nerd but this is total bullshit, I still believe we are here after y2k and I still belive we have computers or do they have us? o0 But serious, this is total bullshit and the Boeing this is not true at all!

30year loan calculation error? hehhe

[PureCreditor]

you must be calculating a $2B loan to overflow it =) i wonder what the monthly payment will look like on that 30-year fixed subprime mortgage

Only 32 bits?

[spazzm]

The java 64-bit time format won't roll over until 292278994-08-17 07:12:55.807 (UTC). Yep, that's over 290 million years from now. I guess that should give plenty of time to move to 128-bit architectures. :)

You mean this crash wasn't planned?

[saintory]

So the recent housing loan problems were not a test to see what would happen when loan companies crash?

Y2K38?

[STrinity]

"Y2K" was a stupid appellation to begin with, but at least it saved one character compared to "2000." "Y2K38" on the other hand is one character longer than just 2038. You're just wasting electrons writing it the other way.

Re:Y2K38?

[Jeng]

Yes, but if you say 2038 to someone they'll think of the year. Y2K38 gives ignorant people like me enough context to know to say "Huh?"

Stupidity for the stupid.

Re:Y2K38?

[spiral]

What's more, "Y2K38" doesn't accurately describe the problem.
I suggest "Y32b" or "Y4B" as more appropriate descriptors.

You'll thank me in 28 years or so when Peter de Jager Jr. makes it a household term.

Re:Y2K38?

[rubycodez]

Y2K38 doesn't mean 2038, it means the problem 32 bit Unix time will have in 2038. This saves many electron storage bins. I'm more worried about the U.S. Y2K8 problem, changing oligarchs doesn't fix oligarchy

IRA

[Anonymous Coward]

Yeah my wife contributes to the IRA through some guy called Charles Schwab. I am surprised that guy hasn't been sent to Gitmo for funding a terrorist organisation.

Re:2038!?!! Get off my lawn!

[Jehosephat2k]

My Timex will still keep on ticking.

yeah but come on!

[Anonymous Coward]

yeah but come on! those were 2999 US people thats gotta balance out when you compare it to the lives of third world people. I mean look at the revenge numbers in Iraq and Afghanistan! and there's still more terrorist out there to get too!

So...

[Anonymous Coward]

32bits of time ought to be enough for anyone? BTW, Bill Gates never said "640k ought to be enough for anyone" idiots, it was IBM (you know, the huge linux backer these days) that limited the PC by choosing a 16-bit chip, the 8088, of course 16-bits = 1MB, and IBM reserved 384k of that for the BIOS. Yet you idiots will continue to say "640k ought to be enough for anyone" and mock Bill Gates for shit that was not his fault, while idiots who do this shit for real (IBM and unix programmers) get a free pass. It's no surprise only .63% of people use linux, according to hitslink (huge web hit-counting site), because nearly everything the OSS/Mac communities do has similar problems of logic, and people are not blind to such things.

Re:So...

[Mesa MIke]

1 megabyte is 20 bits of address space. 16 bits only gets you 64k.

The year 9999

[Ivan Pistoff]

What I want to know is... What happens after the year 9999? Ever think of that?

Re:The year 9999

[WillAffleckUW]

What I want to know is... What happens after the year 9999? Ever think of that?

I think we go hex then. You know, A000.

Re:The year 9999

[Alaria Phrozen]

Wouldn't it be 999A? Or are we jumping from the year 39321 (0x9999) to the year 40960 (0xA000)? God why am I so anal...

The DoomBrood will have died off

[rholland356]

Within 30 years many of the original Y2K DoomBrood will have died off, or entered a state of dementia, brought on by decades of muddy thinking.

And the doombrood spawn--what few there may be--will have robot slaves created specifically for remediation. That, and a legacy of faulty numerology will keep them from crying TEOTWAWKI in every newsgroup.

Good riddance!

Obligatory: year 0 problem

[Anonymous Coward]

This year 2038 problem must be nothing when compared
to the problem of year 0...

Translated from a latin scroll, dated 2 BC:

Cassius

Are you still working on the year 0 problem? The change from BC to AD could cause a lot of trouble,
and we haven't got much time left.
Will people start working backwards?
Thus far we have been happily counting downwards, and now
we suddenly have to start counting upwards?

One would think that people ought to have thought about this
a long time ago, instead of letting us think about this in the very last moment.

I recently spoke to Ceasar. He was furious about
Julius not taking care of it when he made the calendar.
He said that he could see why Brutus got so mad.

We sent for Consultus, but all he said was that
it would be no good continuing counting downwards
with minus BC, and as usual he charged a fortune
for not doing anything constructive.

I don't think we'll have to throw away all our hardware
and start over though.
Macrohard is probably again going to make fortunes on this.

The bankers are of course being paranoid.
They're told that all their interest will reverse,
so they'll have to pay their customers to raise a loan!

All this could get dangerous very soon.
I'm told that three wise men from the east are working
on the problem, but unfortuneatly they're not going
to arrive here till after everything's over.

I've heard that there are plans for putting all horses in the stables
before midnight by the new year, because a lot of people
are worried that they'll stop and try to run backwards,
which could cause a lot of damage on horsewagons and possibly
put lifes in danger. Somebody claims that the world will come to an end at
the start of year 0.

Anyway, we're still working on this confounded year 0 problem.
I'll send you a scroll if we find anything new.
If you get any ideas, please let me know!

Plutonius

Re:2038

[Iron Condor]

The latest time that can be represented in this format, following the POSIX standard, is 03:14:07 UTC on Tuesday, January 19, 2038.

Exactly! Let me emphasize that: This is NOT a "unix problem". This is a POSIX problem. Which means that it affects your cellphone, your media-PC and your favorite ATM just as much as any leftover unix box out there. p(Except that your cellphone and your media-PC will be obsolete by next Wednesday and aren't used to calculate 30-year mortgages).

Got hit by the Y2K bug - in 2008

[dbIII]

Strangely enough I got hit by a Y2K bug last week which will not get fixed for several months. Some idiot decided that 0000 would be good for a permanent licence - which means all the new permanant licences for a product my company is using expired on 1/1/2000. The work around the vendor approved is to disable the licence checking software entirely for the six to nine months before a solution is released. Don't you love expensive closed source abandonware?

Re:Got hit by the Y2K bug - in 2008

[eh2o]

That reminds me of Mysql, which silently converts invalid or unspecified dates to "0000-00-00 00:00:00". When I first saw this happen I did a double-take... I cannot imagine why someone thought this was a good idea. This odd behavior was finally fixed in version 5.0.2, which generates an error when strict mode is enabled and a warning otherwise.

Re:Got hit by the Y2K bug - in 2008

[Splab]

MySQL has a history of choosing best effort rather than correct service. Most people aren't aware of warnings and probably only will be when their data is so messed up its unrecoverable. A fun little example is to create some table using InnoDB, decide you need more log space, modify the log parameter and restart the server, create some more InnoDB tables with FK to the first set and start using the database.

What happens (well used to, haven't checked the newest version) InnoDB can't figure out how to resize the log file so it disables the engine, when told to create table MySQL says, that engine isn't available, I'll just create them as MyISAM and throw a warning. So unless you check those warnings you now got an environment that is bound to get messed up.

Re:I Emulated VM on current o/s

[tengu1sd]

Older code is running on emulators now a days. The fastest VAX ever is modern Intel box emulating the older hardware. This allows older applications to continue to run, covering the loss of source code in some cases.

The issue will be what's running in the back room. Just like Y2K, anyone who wants to be in business and avoid the lawyers is going to have to do some prep work.

slow news day

[Anonymous Coward]

Another kdawson special. Thanks for keeping us fed, even if its from the bottom of the barrel.

Douglas Adams Said...

[GaryPatterson]

"Computer people are the last to guess what's coming next. I mean, come on, they're so astonished by the fact that the year 1999 is going to be followed by the year 2000 that it's costing us billions to prepare for it."
      - 1999, Douglas Adams

This reminds me a lot of that time. Frankly I'm a bit amazed that designers tried to stuff dates into 32 bits, guaranteeing a failure some time in the (then distant) future.

I know memory was once a premium, but a few extra bytes would've allowed thousands of years instead of less than a hundred. Of course, at the end of the thousands of years someone will probably be sifting through the ancient source code of the ancestral computers and being paid very well to fix the Y18K bug.

Why will there be a problem Saturday?

[chrismcb]

I don't get it. Why should there be a problem this Saturday? If I'm calculating the amount of a loan I'd use the number of years (30) possibly the number of payments (30 x 12 or 360), the percentage rate, and value of the house/car. Where does the date come in? its been a while since I've taking accounting 101, but I'm pretty sure the formulaes are date agnostic. Perhaps after I'm done computing the payments, I might print out a payment calendar (for the whole 30 years!) In which case I'd use a tried and true algorithm that doesn't use the time_t command to figure out what day of the week Jan 19, 2038 falls on. I mean I guess I can add 604800 to some value of time_t to move forward a week, although that doesn't help me figure out the day of the week a month from now.

Re:Why will there be a problem Saturday?

[todslash]

It's very unlikely that there will be any problems on Saturday.

It's taking advantage of the anniversary to basically do a Public Service Announcement for programmers.

If everyone's aware of the problem then they will have it in the back of their mind and take precautions when doing time-related coding.

It's a lot easier to take care of it when we're actually writing the code rather than panicking about it when it's only a few years away.

Coverage Difference

[nurb432]

It wasn't about numbers, or lack of caring. One was a natural disaster. The other was a calculated malicious attack.

Not a significant date

[Eric Smith]

Last year at this time was the beginning of a 31-year countdown to the Y2038 problem. This time next year will be the beginning of a 29-year countdown. There's nothing special about 30 years.

Re:Not a significant date

[Mesa MIke]

30 years is the standard length of a mortgage loan.

Re:Not a significant date

[El_Oscuro]

For some odd reason, I didn't get my mortgage bill this month and had to call the company to arrange payment.

2012

[Anonymous Coward]

Meh. Hell with your 2038 bug. I counting on the world ending by 2012.

There's PLENTY of time.

[Mesa MIke]

We'll fix it later.....

2038

[Anonymous Coward]

No! It can't happen then! It'll completely derail the Year of Linux on the Desktop!

There, fixed that for ya...

[repvik]

gniting almost 7 years of war on civil rights and liberty

We're all gunna die!!!

[tristian_was_here]

Ahhhhhhhhhhh......... we are all going to die!!!!!!!!!!!!

It's here already

[dokebi]

On the front page, all the articles have 25 comments. Coincidence? Think not.

ah poop..

[digitalbountyhunter]

Does this mean I should update the firmware of my abacus? I dont think there has been an update for a few thousand years. I once used a Egyptian Firmware Patch with a Roman Abacus, and it rendered the thing unusable. Not only that, but later that week - my dog was killed my a plague of locusts.

Re:ah poop..

[lawpoop]

Try using the Mayan calendar. It's a circle, so you can keep using it on and on into the future. A big rollover is coming in 2012! Every 25,920 years, the sun completes is journey around the sky ( known as the Precession of the Equinoxes in the west ) and returns to the dark center of the Milky Way to be reborn.

Microfortnights

[refactored]

Ah but VMS had a system config parameter in units of microfortnights.

Filesystems Already Fixed

[taylor_venable]

One of the biggest problems (if not the biggest problem) here is in the filesystem. FreeBSD at least has had this fixed for several years since UFS2 uses 96-bit time structures: 64 of those for seconds and 32 for nanoseconds. The kernel, on the other hand, and from a cursory glance, seems to have support ready (i.e. functions to convert and utilize 64-bit time_t values) but not in place by default [e.g. sys/kern/subr_clock.c has a section to return EINVAL when the year > 2037]. Please correct if I'm wrong.

Hey, there you are.

[gr8scot]

Thanks for the sig!

Comment removed

[account_deleted]

Comment removed based on user account deletion

Anno Domini history

[HeroreV]

I know it's probably a joke, but for those that don't know: The Anno Domini epoch was not created until 525 AD, and it didn't really start catching on until around 800 AD. It was certainly meant to be placed somewhere near the birth of Jesus though.

That's just postponing the inevitable.

[raehl]

Fortunately 64-bit numbers can now be handled by pcs, and can be used as an extended timestamp to get a few billion years of time.

Sure, we could to that, but then even if we use an unsigned number, we're still just going to be fucked again in AD 584,542,050,060.

And, by the way, 5+8+4+5+4+2+5+6 = 39, which is the number of weeks in a human pregnancy, which means the 2nd coming of Christ and the apocalypse.

All because programmers were too lazy to use 128-bit numbers to represent dates.

Windows

[Rorian]

Windows (XP, at least) rolls around at 2099. I'm planning for the long term, and starting a company that fixes issues arising from the Y2K100 (TM) bug. Once I find a VC willing to wait for 92 years to see a profit, I'm so made.

Y2K

[alxkit]

Y2K? what are you selling : chicken or sex jelly?

-Peter Griffin

Why are you so anal?

[Anonymous Coward]

It's better than being c-literal?

Orange you glad I didn't say vaginal?

Re:The answer is 64! .. Not on virtual macines

[baileydau]

By 2038, no major consumer cpu manufacturer will be producing anything but 64 bit chips. While this is probably true for new machines, but nowdays people / companies are increasingly using virtual machines to extend the life of "essential software" long after the original hardware has given up the ghost and it is not easy or convenient to move to new hardware.

Where I work, we have one such machine that now runs some software that no one is game enough to touch.

In theory the software that runs today can be made to run indefinitely by putting it in a virtual machine (within a virtual machine host - within a virtual machine host - ad infinitum).

For them the world is still very much 32 bit.

No, the GP was correct....

[brunes69]

When oh when will the never-ending sensationalist description of events that water down the English language end?

If you are talking about an "Apocalyptic event", neither of these things even register on the radar. A few K die at 9/11? Please. A few hundred K die in a Tsunami? Worse, but still not that bad historically. Tens of millions died during the black plague, it wiped out 2/3 of Europe's population, and even that is not an apocalyptic event.

An "apocalyptic event" is an event that - guess what - could be mistaken for THE APOCALYPSE in it's early phases. Something that wipes out billions of people.

Averages causing overflows

[todslash]

It's not a big issue and as long as programmers are aware then hopefully it will be avoided.

But there are pitfalls out there now which naive programming may fall into.

I came across this one at http://www.2038bug.com/. We hit the 31st bit of POSIX time in 2004. That means that if you add together any two current times, for example when taking an average, then you will overflow a 32 bit signed integer.

Apologies for code quality but this artificial example hopefully shows the issue:

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <time.h>
int main ()
{
time_t t,t1,t2;
struct timeval tnow;
gettimeofday(&tnow,NULL);
t1=tnow.tv_sec;
printf ("Time now: %s", asctime (gmtime (&t1)));
t2=t1+100;
printf ("Add 100 seconds: %s", asctime (gmtime (&t2)));
t=(t1+t2)/2;
printf ("Average: %s", asctime (localtime (&t)));
return 0;
}

gives the following on my x86 Linux system:

Time now: Wed Jan 16 11:43:18 2008
Add 100 seconds: Wed Jan 16 11:44:58 2008
Average: Fri Dec 29 08:30:00 1939

It's easy to fix by casting to 64 bit or dividing first but there may be similar examples hiding away in old code which are less easy to spot.

Or 65, as in 6502?

[tepples]

It is possible that a revolutionary new concept in processing will result in an insanely fast processor but technological limitations will force it to only be 8 bits. You mean like the 6502-based microcontroller used in a T-800's vision? An 8-bit 6502 processor can process 64-bit values; it just takes more cycles to do so.

I want higher resolution time stamps...

[alispguru]

... especially for files. These days, for small projects, compile and link can take much less than one second, especially if all the files are in the system cache. Having all the files in your project with the same timestamp can confuse tools like make, which will then rebuild stuff unnecessarily.

If we're going to 64-bit timestamps, could we consider giving up, say, one or two bytes for fractional seconds?

Multics is 71 bits microseconds from 1900

[igb]

I have it on suspicious authority that the mechanism may be inherited from a Multics mechanism with a different epoch date, but I cannot find proof.

Multics, certainly by the time I was using it in the early eighties but I believe from much earlier, used microseconds since 01/01/1901 stored as a fixed bin(71): a double word quantity on a 36-bit machine. That allows you to represent about 75 million years each side of the epoch to microsecond resolution. Multics needed microsecond resolution because the generation of several vital unique quantities, notably process directories stored in >pdd>long-random-string, were obtained by reading the clock and then doing the equivalent of base64 encoding it. The clock was locked during read so that only one process could obtain a given clock value.

You can look at the documentation for the Multics equivalent of ctime, date_time_ () at http://web.mit.edu/multics-history/source/Multics/doc/info_segments/date_time_.info. You get the basic timestamp with block_ () http://web.mit.edu/multics-history/source/Multics/doc/info_segments/clock_.info. I have a feeling that times were stored in the filesystem as 54 bit quantities (a word and a half), giving the same range but only quarter-second resolution, to save space, but I can't quickly find the documentation for that and I can't put my hand to any source code that would show it in use.

Unfortunately, that is how history is made...

[Anonymous Coward]

Or, as would Lemony Snicket say, "The moral of World War One is 'Never assassinate Archduke Ferdinand.'"

But you should really add to the 4000 ppl that died in the 9/11, 9/12 and 7/7 the 1.2 million people that have died as a consequence of USofAn actions, mainly in Iraq.

Expiry dates

[Evil Pete]

I've already been affected. An application I work on has in a remote corner of its innards a check for expiry time of certain proximity cards. These are not credit cards. The real expiry dates were past 2040. The library which uses standard 'time' returning a time_t is 32 bits. So only goes to part way through 2038. Had to fake the rest. Hopefully when we get closer either the company will be bust, the OS will be 64 bit or the code will be revamped ... likely all three.

2038 is more fundamental than y2k. y2k was a problem because of a choice made by some developers. But the end of the unix epoch is common to almost all large C / C++ applications, and not just unix. I expect this to be dealt with semi cleanly, maybe a redefinition of time_t etc. Yeah it's more complicated than that, I haven't looked into the plans.

One gigasecond already past

[PetiePooo]

Being that the unit of measurement for time_t is in seconds, why would you use an arcane unit of measurement like a year to mark one of its milestones?

The big milestone already past us around January 10th, 2004. We now have less than one gigasecond remaining! Everyone get their survival kits and fallout shelters prepped...

2^30 = 1,073,741,824 sec
1,073,741,824 / 60 / 60 / 24 / 365.25 ~= 34.025 yrs
0.025 yrs ~= 9 dys
1/19/2038 - 34 yrs & 9 dys = 1/10/2004

2038 is greater than 2012

[Anonymous Coward]

2038 after 2012; the calandar will rollover to 0 on 2012 so there is nothing to worry about. Time will take care of itself without you counting its seconds.

Uh-huh, and what about stored data?

[jonaskoelker]

Right, you do a simple recompile of the serialization library of your spreadsheet (or whatever), then start interpreting the 32 bits following the stored 32-bit time as part of the 64-time. Mmhm. It'll "just work". For some real fun, do it on your file system.

(now, the conversion is presumably not that hard to do, in either direction, but it still has to be done).

Re:Uh-huh, and what about stored data?

[gweihir]

If serialization has been done according to the Unix philosophy, again there is no problem, since the storage format will be plain ASCII in human readable format and parsing it into 64 bit values will not be an issue at all and no "conversion" will be necessary. The limitation you are talking about is primarily present in the competence-challenged "Microsoft World", were flashy GUIs are valued more than long-term compatibility, reliability, portability end general respect of good software engineering practices.

Not Americans.

[Anonymous Coward]

Or did you not know most famine children in Africa are black?

Sane people?

[hummassa]

I've been working in development for more then 20 years now (since I was 17 -- and I am going 38 this year) and I never, ever, found anyone in the trade that can be considered "sane" by any, less strict possible, definition.

Re:Sane people?

[Hognoxious]

I never, ever, found anyone in the trade that can be considered "sane"

So have I and trousers, I totally carrot.

Bingo...

[Julz]

Yikes. I didn't think this would affect the company I'm working for but it does. They use Pike/Roxen and the Pike module Calendar.pmod module is causing an "Internal Server Error" because it being asked to look 30 years into the future.

Are we fixing this now?

[Bushido Hacks]

Eight years after the Y2K scare and thirty years until the Y2K38 scare, why don't we just add another 32 bits to the tzdata package? I mean, 64 bit systems won't have to worry about it too much, right?

In italian language

[lobotomia]

I have spoken about this in italian language: http://www.pettinix.org/2007/12/29/siamo-a-fine-anno-il-2038-si-avvicina/

Y2k38 WTF?

[Trogre]

Why bother calling it Y2K38 except to sound cool? Y2038 uses the exact same number of characters and is more correct.

Y2K38, in engineering circles at least, would mean Y2.38K, or Y2380. To keep using the 'K' terminology from Y2K, you'd need to say Y2K038, which is, well, just silly.

Value of life

[galanom]

1 American life > 100k non-American lives
1 Israeli life > 1000 Palestinian lives
Iraqi Petrol > 650k-1.3M Iraqi lives
American Pride > 3000+ American soldier's corpses

Now that you learned these (in)equations, can you differentiate
an ex-american-funded terrorist organization (al-Qaeda) and an
armed liberation army who fights for the independence of their country (IRA)?
(yeah, I know that a fraction of IRA signed the dissection of Ireland, but this
was never accepted by the head of IRA)