Live data from Hacker News

2038: Only 21 years away

lwn.net

251–260 of 333 posts

Re: 2038: Only 21 years away

#251

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

Most backup cameras already work via the center entertainment console LCD and the trend is for climate control to move there too.

Re: 2038: Only 21 years away

#252

On 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?

Distinguishing between "unknown past" and "unknown future" is helpful if you're going to be sorting things on date.

Re: 2038: Only 21 years away

#253
post #200

Earlier quoted context omitted.

A Fire Upon The Deep is a fantastic book as well.

I loved both of these, any recommendations for other similar books?

The only one I can think of that's remotely in the ballpark would be Dune. The creativity in AFUTD is hard to match.

Re: 2038: Only 21 years away

#254
post #46

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

You can buy new PDP-11 and VAX hardware to run Unibus/Q-bus based industrial control systems today: http://logical-co.com/

Re: 2038: Only 21 years away

#255

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. :)

> 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

#256

The 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.

But since those products were made by developers and tech savvy people, wouldn't it be their fault for releasing a product capable of doing that? It's literally their jobs to do so. Just as doctors and lawyers don't just assume patients/clients will know everything about their fields, why should we?

Re: 2038: Only 21 years away

#257

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…

What's up with that huge weekly variation?

Offices. Corporations hugely lag in technology: I still continue to run across Internal App™ at Big Corp Inc that only works with IE 6 — and that's not just lagging, that's ancient. It should be no surprise their Internet infrastructure also lags. My current and last two employers both were IPv4 only.

Re: 2038: Only 21 years away

#258

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.

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…

There was almost certainly some forms of relatively advanced seafaring 8000 years ago possibly including skin boats, sails and paddles, ropes, sealants and astronomy. Also, fairly sophisticated metallurgy was widespread with at least silver/iron/gold, possibly bronze. Writing was known to some cultures. Horses, camels and water buffalo were likely all domesticated. Use of drying/smoking for preservation and curing of meat. Yogurt may have been known in some areas. Advanced pottery. Probably nontrivial herbalist / medicinal / architectural / construction knowledge. Plus of course trapping, fishing, textiles, stonework, etc.

Re: 2038: Only 21 years away

#259
post #117

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

Every employer except one that I've worked for had IPv4 only. None of them had public IP blocks; they were all NAT'd.

> 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

#260

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)

I wanted to figure out the importance of that value you found, so I went and did some further research. It turns out the greatest date you can create in Javascript is Date(8640000000000000). Interesting!

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

Post reply on HN