301–310 of 333 posts
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.
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
reek v. To give off a foul odor wreak v. To inflict or execute
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. :)
Nobody will care about significant year digits in a few billion years
Earlier quoted context omitted.
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?
Let's not even get into timeval which uses the same size field for microseconds.
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.
Earlier quoted context omitted.
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 havin…
>experience with humans So true. That said, thinking 38 years into the future is usually not sensible for most businesses, because it's very possible that they're bankrupt before then. Thinking 21 years into the future also offers poor ROI for the same reason.
Strikes me that big businesses would have thought "will we need to do this again in a few years" and acted appropriately and that there should be a trickle down effect as large corps demand future proofing in IT products.
Yes negligence, ignorance, lack of foresight, corner cutting, and other human traits feed in to that.
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."
Earlier quoted context omitted.
>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?
That level of detail isn't published, but most of Guatemala's IPv6 traffic is coming from http://bgp.he.net/AS52362 and http://bgp.he.net/AS23243 Edit: APNIC has similar data published here: https://stats.labs.apnic.net/ipv6/GT
Earlier quoted context omitted.
https://en.wikipedia.org/wiki/Year_2038_problem Short summary: Many systems (including Unix) store time as a signed 32 bit int, with the value 0 representing January 1st 1970 00:00:00. This number will overflow on 03:14:07 UTC on 19 January 2038.
So a more serious Y2K?
Y2K is more of a formatting / digit representation problem than a pure data type overflow. The solution for Y2K was to switch the representation of year from 2 to 4 digits, along with coding and logic changes to go along with this.
For Unix / Linux, the solution for the 2038 problem involves changing time_t from 32 bits to 64 bits. At a higher level (eg what's in your C++ code), instinctively I don't think this in itself would involve as many code changes (maybe some data type changes, but probably less logic changes than Y2K, that's my guess). I believe several platforms have already moved towards 64 bit time_t by default... some support this by default even on 32 bit systems, such as Microsoft Visual C++ -- https://msdn.microsoft.com/en-us/library/3b2e7499.aspx
Since this involves a data type overflow issue, though, we're dealing more with platform specific / compiler / kernel type issues. I don't know, for instance, how easily 32 bit embedded type systems could handle a 64 bit time_t value. I understand that there are some technical issues with Linux kernels (mentioned in some of the comments) that prevent them from moving to a 64 bit time_t irregardless of platform (time_t should always be okay on 64 bit platforms, it's the 32 bit platforms that will have the issue...)
The good news is we have 21 years to think about it...