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

171–180 of 333 posts

Re: 2038: Only 21 years away

#171

Post by __jal »

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.

If you were around for the millennium bug, then surely you remember how many people waited until about October, '99 to start looking for problems. If you think those people went looking for another problem 38 years away to fix...

If this class of business is not seeing a problem this minute, it isn't a bug. And it won't be a serious-enough bug to spend money on until whatever workarounds they can think of start having negative effects on income.

Sources: experience with Y2K remediation, experience with small business consulting & software development, experience with humans.

Re: 2038: Only 21 years away

#172

Post by runeks »

Using a 64 bit unsigned integer with nanosecond resolution gives us 585 years (2^64/1e9/60/60/24/365) after 1970 to come up with a new format. This, combined with using some other format to describe dates before 1970, seems like a sensible solution to me.

Re: 2038: Only 21 years away

#173

Post by __jal »

drzaiusapelord wrote: post #110
archgrove wrote: post #9

Earlier quoted context omitted.

It wasn't intended to be sarcastic. I suspect there will be a lot of businesses (especially finance) interested in verifying that the "ancient" Linux system they setup to replace their mainframe 25 years "ago" is safe. I lived through the Year 2000, and watched the same thing happen there. With suitable groundwork, there will be a willing and wealthy market looking for people to assuage their fears - a service I see…

>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…

It isn't 1000 seats, but I know of a Win98/NT4 shop. It is an isolated network supporting mostly phone sales and pick-and-pack, runs some ancient copy of MAS90 and some home-grown software.

These installations exist, and (outside of tech startupland) isn't even that strange, although he is probably pushing things. The owner of that business is proud of how long he's made his IT investment last; his main concern is that dirt-cheap second-hand replacements that can run 98 are apparently getting harder to find.

Re: 2038: Only 21 years away

#174

Post by magpi3 »

minikites wrote: post #145
AndrewKemendo wrote: post #144

Can someone ELI5 this please? The only thing that seems comparable that I know of was the "Y2K bug" - but reading through this it seems like this is actually a big problem - as opposed to the techno-illiterate panic of Y2K. That work, he said, is proceeding on three separate fronts I can't read that without thinking of the turbo encabulator.

I'll let somebody else handle the explanation but Y2K wasn't a "techno-illiterate panic", a ton of people worked a ton of hours to fix and update the code for Y2K and it's a testament to their labor that there were no major issues.

It was a combination of both. I still remember my dad coming home from a talk that he considered the "best yet" on the Y2K issue.

The speaker warned that traffic lights would stop working. Maybe someone more techno-literate than me can explain why that would be a genuine concern, but from my perspective at the time it seemed like the guy was making money from fear mongering.

Re: 2038: Only 21 years away

#175

Post by samuraig »

calt wrote: post #156
drzaiusapelord wrote: post #125

Earlier quoted context omitted.

No 2016 beagleboard implementation will be running BigCo's finances and be irreplaceable in 2038. Lets be realistic here. Those 70s and 80s programmers were working on mainframes with multi-decade depreciation. We work on servers and projects with 3-5 year deprecation when we aren't working on evergreen cloud configurations. Not to mention we've already standardized on 64-bit systems, outside of mobile, which is soon…

I've worked on financial systems still running on mainframes from the 80s. The Y2K compatibility commit messages are there in the logs. Airline reservation systems run on software written in the 50s and 60s Your views on evergreen this and disposable up to date that are very naive. Embedded systems and business systems live for a VERY long time.

but their mobile enabled recipe site is TOTALLY going to be around for a long time too!!! ;-)

Re: 2038: Only 21 years away

#176

Post by runeks »

1maginary wrote: post #74
deathanatos wrote: post #50

Earlier quoted context omitted.

You jest, but global IPv6 penetration is at ~16%. It rose ~6% last year, so if linear growth is presumed (and it's actually been growing closer to exponentially, as would be expected) we should hit 20% late this year. I'm hopeful that we'll see some decent pickup of it since AWS finally started offering it. This is global adoption; some countries, including the United States, have already hit 20%. [1]: https://www.go…

>The graph shows the percentage of users that access Google over IPv6. I'm finding it really hard to believe, as someone in Guatemala, that 6% of requests to Google here are made over IPv6. Is there any way to gain more insight? e.g. what ISPs are responsible?

Mobile carriers. In the US, 55% of mobile traffic is IPv6: http://m.slashdot.org/story/315213

Re: 2038: Only 21 years away

#177

Post by steffan »

Despite the cause being the end of the UNIX epoch in 2038, problems will become apparent a much sooner. Like the Y2K issue - in ~2031 (or sooner), systems that track expiration dates or contract terms will start to run into dates past 2038. As 2038 approaches, more systems will be affected (there are relatively fewer expiration dates 7 years out vs. 5 or 3).

The effects of this problem are closer than they seem - only 14 years away or less

Re: 2038: Only 21 years away

#178

Post by spencermountain »

for the others curious, seems javascript handles dates with 64-bit floating points, which have a maximum of 9007199254740991.

The highest date I could make with node+chrome was 'Dec 31 275759', which cozies-up pretty close to that (8639977899599000)

Re: 2038: Only 21 years away

#179

Post by Razengan »

Retric wrote: post #85
ejcx wrote: post #58

Earlier quoted context omitted.

If humans are still alive 292million years in the future, seems like that's our best time to take control back from our sentient AI overlords.

I think this would make a great science fiction setting. Where some clock error destroys most/all the magic tech out there and humanity is doing hunting and gathering on space stations etc.

On a tangent, take a look at Numenera [0][1]. It's set a billion (!) years in the future, but different from other ultra-science fiction or post-apocalyptic settings in that it primarily explores what Earth would be like after accumulating multiple layers of incomprehensibly advanced supertechnology, the true purpose of which cannot ever be understood by the current inhabitants, and at best they can only reverse-engineer a fraction of the original functionality.

[0] http://www.numenera.com

[1] store.steampowered.com/app/272270/

Re: 2038: Only 21 years away

#180

Post by asperous »

keithlfrost wrote: post #54
antirez wrote: post #24

Using a 64 bit timestamp will only move the problem 292 million years forward, so probably the best solution is to use a variable length field.

On the other hand, using a 64 bit integer to count seconds moves the problem 292 billion years forward, and we can probably let the Omega Point handle it from there.

292 Billions years ought to be enough for anybody
Post reply on HN