Earlier quoted context omitted.
The problem is that if you want to manufacture a device that will last 20 years without updating its software, then you have to fix this issue within a year - otherwise the washing machine, car, stereo or whatever you release with embedded chips and currently standard software can fail in interesting ways in 2038.
I don't really see the problem with cars, none of the important parts require time
2038: Only 21 years away
251–260 of 333 posts
Re: 2038: Only 21 years away
#252On a side but related note, I don't understand why many programming languages and databases don't have a positive and negative infinity date placeholder/token value that is standardized and cross platform. Negative infinity date is "past", positive infinity date is "future". This would solve the common problem of what date to use when you are trying to talk about unknown date in the future or unknown date in the past…
There are lots of scenarios where you need to represent an unknown/indefinite date, but this can be done with null; are there any reasonably common scenarios where you need to distinguish between unknown past and unknown future in the same context?
Re: 2038: Only 21 years away
#253Re: 2038: Only 21 years away
#254Call 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...)
There are still lots of systems from the 70's and 80's running today. There are many PDP and VAX systems that run parts of the US military, such as missile defense and nuclear ICBM systems. Many airlines and insurance agencies also run on mainframes from that era. Even if they don't run the actual hardware, they're likely to be running the same software and OS on an emulator running inside modern hardware. It's simpl…
Re: 2038: Only 21 years away
#255Earlier 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. :)
Hopefully they don't have any octal-related bugs.
Re: 2038: Only 21 years away
#256The problem is not with developers or tech savvy people. Everyome will know about this by then and solutions will be applied. The problem is with end users, who will only realize this after the shit hits the fan and their fridge will go crazy or there will be a car crash.
Re: 2038: Only 21 years away
#257Earlier 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…
What's up with that huge weekly variation?
Re: 2038: Only 21 years away
#258Earlier 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.
Yes, I know some of us will never retire. 8000 years in the future career planning is an interesting thing to think of though. 8000 years ago the only thing that was going on was some neolithic agriculture. Domestication of the Jungle Fowl (modern day chicken) in India and the beginning of irrigated agriculture in Sumeria were probably the biggest news items of that millennium. I guess someone from 8000 years ago cou…
Re: 2038: Only 21 years away
#259Earlier 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…
> Also they tend to rely more on enterprise network appliances which have bad IPv6 support in my experience.
This I would believe.
> IPv6 is more of a boon to consumer applications since carrier-grade NAT is a nuisance and otherwise you need an IP per customer.
It would have been a slight boon at work, too. HR perennially makes me grab documents/data off my home machine, and I cannot wait for the day when I can just `ssh` to a domain name. My .ssh/config aliases are getting pretty good, but it still adds considerable latency to pipe everything through a gateway. (Alternatively, I could run SSH on non-standard ports, but I've yet to get to mucking around with the port-forwarding settings for that.)
There were also times when we needed to do stuff like employee laptop-to-laptop communications, and the network just wouldn't deal with it. I was never sure if this was NAT, or just that Corp Net liked to drop packets. (It seemed rigged to drop basically anything that didn't smell like a TCP connection to an external host. ICMP wasn't fully functional, which of course makes engineering more fun when you're having your personal desktop at home do pings or traceroutes for you, but that doesn't help if the problem is on your route.)
Re: 2038: Only 21 years away
#260for 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)
From the ECMAScript Spec [1]:
The actual range of times supported by ECMAScript Date objects is slightly smaller: exactly –100,000,000 days to 100,000,000 days measured relative to midnight at the beginning of 01 January, 1970 UTC. This gives a range of 8,640,000,000,000,000 milliseconds to either side of 01 January, 1970 UTC.
[1] http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1