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.
At which point we'll all still be too distracted by deciding which JavaScript build system to use.
2038: Only 21 years away
131–140 of 333 posts
Re: 2038: Only 21 years away
#132Earlier quoted context omitted.
What's up with that huge weekly variation?
It looks like it's correlated with the weekend. I guess workplace computers are more likely to use IPv4? It makes sense on the surface. Workplaces have little to no incentive to use IPv6 since they either have a huge block of IPv4 space or run NAT or both. Also they tend to rely more on enterprise network appliances which have bad IPv6 support in my experience. IPv6 is more of a boon to consumer applications since ca…
Makes sense.
Re: 2038: Only 21 years away
#133This 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.
Same, I'll be 55. My son will be 23. Either our generation fixes it, or his generation will have to fix it in their first jobs out of college (sorry kids!)
Re: 2038: Only 21 years away
#134Earlier quoted context omitted.
It won't be the same magnitude of issues. However, I'm sure there will be plenty of apps on said 64 bit Linux that have issues. I commented about a mysql problem here that exists on 64 bit MySQL, on 64 bit Linux. It's not much of a stretch that some internal apps at a company would have similar issues. Edit: Ntp has something of a protocol issue to be addressed as well.
Yeah but that's a protocol issue. Single graybeard devs aren't going to be paid to fix that. The people who run ntp are going to push out a new protocol way before 2038. Even if there are issues, more than likely they'll be able to handle it internally. OO programming isn't going anywhere and modern languages and concepts are easier to work with than piles of undocumented COBOL from Y2K. They won't be calling you wit…
Right, but at a high level, I'm answering why there might be money in consulting on this later.
There will be Fortune 500 companies that have old ntp clients running somewhere in 2038...pretty much guaranteed. They'll also have apps with 32 time_t structures running as well, database columns that overflow, etc. Or maybe they won't, but aren't sure. You sell them a service that audits all of those things, scripts that look for troublesome stuff using source code greps, network sniffing for old protocols, static analysis, simplistic parsing of ldd, etc. And, a prepackaged methodology, spreadsheets, PowerPoint to socialize the effort, and so on.
It was the same for Y2K. Fixes for many things were available well ahead of time. Companies had no methodology or tools to ensure that the fixes were in place.
Re: 2038: Only 21 years away
#135Earlier quoted context omitted.
No, you make it time_t (unsigned) seconds since the epoch. That pushes the problem out 70+ years and doesn't break any binary APIs.
Changing from signed to unsigned is very much an ABI break.
Yes, it is an ABI break.
But if you took code that was compiled with each version, the binary data that they will produce/consume for dates between the epoch and 2038 is bit for bit identical.
Re: 2038: Only 21 years away
#136Call me stupid, but I think computing will be much different to worry about this. ( single chip os or iot to the level that each hardware component is separate, or something else...)
True, but this isn't a problem for the hardware and software that will be produced in 2037. The problem is all the stuff that will be built today, and last for 30 years.
We're already bordering on it being a little late. Y2K sucked for the developers of 1999, but they had few computers to worry about. They where less interconnected and all the Unix/Linux based system wasn't at risk. Imaging trying to patch or replace just 20% of the embedded devices when we get to 2036.
What fascinates me is that we didn't start addressing the issue right after Y2K. Perhaps we would have if more computers had failed.
Re: 2038: Only 21 years away
#137Earlier quoted context omitted.
It was a good time to be a COBOL developer.
I never quite understood why the transition from 1999-2000 should be a big deal for a computer system, until I learned about how COBOL works: it stores numbers as its string-representation unless told otherwise, and trying to store 100 in a field of two bytes will happily be stored as "00". Of course we had other bugs, with the same cause, well after the y2k-period.
There is a lot of crappy code out there, it doesn't surprise me at all.
Re: 2038: Only 21 years away
#138[deleted]
Re: 2038: Only 21 years away
#139Earlier 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.
Financial systems that deal with bonds already have to deal with maturity dates on 30-year bonds that are past 2038.
Re: 2038: Only 21 years away
#140Earlier quoted context omitted.
It was a good time to be a COBOL developer.
I never quite understood why the transition from 1999-2000 should be a big deal for a computer system, until I learned about how COBOL works: it stores numbers as its string-representation unless told otherwise, and trying to store 100 in a field of two bytes will happily be stored as "00". Of course we had other bugs, with the same cause, well after the y2k-period.
Not quite literally strings, it typically uses binary-coded-decimal (BCD) format for numbers, but it has the same effect when years are stored as two digits.