Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

2038: Only 21 years away

lwn.net

Post reply on HN
Print view View original

281–290 of 333 posts

Re: 2038: Only 21 years away

#281

Post by gcb0 »

nsxwolf wrote: post #120
AlexC04 wrote: post #44

Earlier quoted context omitted.

I hope you've trademarked the term "epochalypse" because it is really catchy! I love it.

I will be just 5 years away from retirement, so I will use this as an opportunity to shore up my 401k. Of course, the singularity will be here by then and fix it for us just before turning us all into paper clips, yada yada. I will advertise with the slogan "Epochalypse... NOW."

> I will advertise with the slogan "Epochalypse... NOW."

or you can do the same as the y2k people did: Y2K... TOMORROW!

Re: 2038: Only 21 years away

#282

Post by gcb0 »

web007 wrote: post #100
archgrove wrote: post #3

This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.

This is part of my plan as well, thus https://2038consulting.com/ registered 6 years ago.

Genius. Are you accepting A rounds?

Re: 2038: Only 21 years away

#283

Post by tdhoot »

ekimekim wrote: post #264
antirez wrote: post #217

Earlier quoted context omitted.

Pardon, it's billion indeed if you count seconds. I wrote millions for mistake, but thinking about it once you have 64 bits, milliseconds are nice to have...

But once you have milliseconds, microseconds are nice to have... The linux kernel (and many other applications) solve this with a tuple of 64-bit ints (seconds, nanoseconds) where 0 Other systems still (perhaps most commonly) are using double floats for seconds. Under that scheme, nanoseconds were only representable until Feb 17th 1970. The last representable microsecond will be some time in 2106, and the last repres…

Why not just use int32 for nanoseconds then?

Re: 2038: Only 21 years away

#284

Post by gcb0 »

pbhjpbhj wrote: post #92
tyingq wrote: post #63

Earlier quoted context omitted.

Databases too. MySQL has a 2038 bug in their UNIX_TIMESTAMP function. select unix_timestamp('2038-01-19') returns 2147472000 select unix_timestamp('2038-01-20') returns 0

Surely these sorts of errors in major systems are already being/have already been addressed - for healthcare for example a search for which members of a GP's practice are going to be pensioners in 2040 is going to error badly? Strikes me that the time to address them was shortly after the millennium bug.

> Surely these sorts of errors in major systems are already being/have already been addressed [...] search for which members of a GP's practice are going to be pensioners in 2040

If you know anything about programmers, you know they found that error at some point during development, thought about how other people dealt with that, remembered that windows used to treat >30 as 1900s and <30 as 2000s and did the same. So probably the people in this thread planning their retirement solving this will have to figure out which random unix timestamp number is treated as pre 2038 and which one is after. And then they will have to undo all the last-minute spaghetti code tying it up on the original program.

Re: 2038: Only 21 years away

#285

Post by callalex »

MHordecki wrote: post #261
sedachv wrote: post #247

Earlier quoted context omitted.

That is actually how Common Lisp represents time: https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... When you look up "integer": https://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bo... "An integer is a mathematical integer. There is no limit on the magnitude of an integer." What happens when an integer overflows from a fixnum (single-word representation) is that it gets upgraded to a bignum behin…

Python supports arbitrary-width integers too. Its datetime implementation, however, is implemented partially in C, and does not support arbitrary timestamps.

And up until recently didn't even give you access to a guaranteed monotonically increasing clock!

Re: 2038: Only 21 years away

#286

Post by ajdlinux »

sedachv wrote: post #241
drzaiusapelord wrote: post #110

Earlier quoted context omitted.

>verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. The problem with mainframes is that they can't be trivially upgraded or migrated to 64-bit like modern OS's on x86 hardware can be. Vendor lock-in, retirement of OS, bare to the metal coding, etc caused this. If these mainframes were running a modern OS, it would have been trivial to upgrade them to a 64-bit versi…

Pretty much everything in your post is wrong. IBM mainframes are heavily virtualized and have very good support for moving to larger address spaces. VM and MVS moved from 24-bit to 31-bit to 64-bit address spaces. You can run the old 24-bit applications and upgrade them as needed. Even assembly programs - the old assemblers and instructions are supported on newer hardware. System i (System/38-AS/400) was built around…

Also note that IBM mainframes can run 64-bit Linux just fine. Indeed, IBM's been marketing its LinuxONE mainframe line as a z series machine that doesn't run z/OS at all.

(disclaimer: IBMer, but not a mainframe person)

Re: 2038: Only 21 years away

#287

Post by fritzw »

archgrove wrote: post #3

This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.

I hate to be to buzzkill but more than the computer systems is the food supply... climate change is going to reek havoc on our "retirement" we will likely die young starving and thirsty

Re: 2038: Only 21 years away

#288

Post by andrepd »

archgrove wrote: post #3

This is (serious) a part of my retirement planning. I'll be mid-50s when this hits, and have enough low level system knowledge to be dangerous. In about 15 years, I'll start spinning up my epochalypse consultancy, and I'm expecting a reasonable return on investment in verifying systems as 2038 compliant.

https://xkcd.com/607/

Re: 2038: Only 21 years away

#289

Post by hornetblack »

cpeterso wrote: post #219
DannyB2 wrote: post #155

Earlier quoted context omitted.

My retirement planning is to work on the Y10K problem. When the year 9997 comes along, everyone is going to start worrying about the rollover to five digit years. In about the year 9995 I will start seriously brushing up on my COBOL.

My bank's website allowed me to set a recurring monthly transfer until the year 9999. The Long Now Foundation uses five-digit dates like 02017 in their work. :)

People get bans on XBox Live until 9999-12-31 I guess it's probably just an Input validation thing. Also I think it's fair to given most people their account back after that amount of time.

Re: 2038: Only 21 years away

#290

Post by callalex »

jerf wrote: post #71
dboreham wrote: post #48

Earlier quoted context omitted.

I'm not convinced that the problem was considered in those terms. Imagine that there was a meeting where someone said "I'm going to make time_t 64-bits because if I don't it will mean all software will break in unfortunate ways in the year 2038", and someone else said "Yeah, that's something to be concerned about but we can't do that because memory and disk space is at present too expensive to allow it". Well, I'm co…

Yes, people absolutely cared about bits and bytes, because they weren't very many of them. (Programmers weren't necessarily thinking of them as monetarily expensive, because even today you don't just go slamming more RAM in to your machine if you need more. The problem is that there were only so many of them.) You could still see the residual hacker attitudes even five years ago, though I'd have to call it mostly dea…

>even today you just go slamming more RAM into the machine if you need it

Hmm, every software gig I've had in the past 5 years that's exactly what I've been expected to do because the extra ten bucks a month for a bigger VM is wayyy less expensive than engineering time. Interesting times.

Post reply on HN