Many of these devices will still be operating in 2038, but long forgotten. Think HVAC control systems, kitchen appliances, security systems, etc. Cars, trains, information signs, traffic lights, many of these public infrastructure systems will fail.
And these systems are very, very hard to update, if possible at all. We'll be having a lot of e-waste in 2038.
In 2036, factory reset to wipe all state, and keep using the same ancient kernel with a tiny hotpatch to assume 1/1/2035 as time base. If your kitchen appliance is still around by the time that is a problem, you'll get an award ;)
But don't tell anybody, I plan to hawk my consulting skills from 2030-2038 to pad my retirement income. Just like the good old Y2K days & COBOL.
Am I supposed to pull my microwave out of the wall and ship it back to GE? Does it have a USB port for installing this hot patch? How does GE tell me about it?
Devices like your microwave won't magically stop working in 2038. For most non-networked and, in 2038, ancient appliances, there shouldn't be that much of a problem.
Pedantics would say "well just don't buy this IOT crap," but the problem is that only the bottom line devices come this way in a lot of cases.
There are way more "smart" devices (devices with some kind of embedded software and clocks) than we assume, and there are way less of these devices than we fear.
It's still gonna be a problem though.
Remember, the Zune wouldn’t boot in 2009 because 2008 was a leap year, and that wasn’t tested.
I understand that there might be some smart microwaves with Wifi and whatever (setting all sentiments about that aside), but those are not what are meant.
(I'm just trying to guess. Personally I think it's an absurd feature, and on the rare occasion I've had a microwave that even displayed the time, it was always wrong anyway)
Having a date on your microwave could be useful for things like updating the clock for daylight savings time. Or it may be that the clock overflow causes the entire firmware to crash in 2038, bricking an otherwise still functioning device.
That feature is unlikely to work well, tzdata is updated multiple times a year.
(Well, almost all of them are that way. There are a few, precious few, sane parts that are just a 32-bit counter counting up at one second per second. These, of course, are rare, obscenely expensive, large, and missing useful features like trimming. Sigh.)
STMicro's RTC's are the usual POS everyone loathes. All the RTC IC's are also just like that.
I'm looking back at the things that I own today that I owned in 2000. (Or, if you're young, consider the things your parents own that they owned in 2000). It's not a ton, but it's not zero either. And we're equidistant to 2038 and to 2000.
20 or 40 years ago most people expected their devices to last a lot longer than today. Now if you TV breaks down after 5 years most never bother fixing it and just think "I was due for a new one anyway".
That's what they always say but when the time comes the old stuff is still around. Happened with Y2K stuff, happened with old Cobol code.
Anyway, I'm sorta skeptical that a whole lot of things that have been running deeply embedded code for a while now will still be running in 2038. Tech changes faster now, hardware isn't designed to last many decades much any more (at least it's the exception rather than the rule), and there's so much of industry that is going to have to change to overcome future challenges that I expect a great many things to taken out of service before then.
Embedded systems are everywhere, and they’re not all trivially dismissed.
Programs should just use time since boot. And only bother to convert when offered for human or external consumption.
Personally, I deal with trading systems in the US; we record all timestamps in EPT down to microsecond resolution. Currently only deal with US equities, so dont need to worry about DST. I would prefer timestamps were in UTC, but well, legacy systems...
The point is that there is no necessary _strong_ _low-level_ connection between 'how long ago something happened on this computer' and how many years since the birth of JC.
Personally, while I appreciate your arguments, I'm not sold on them.
If so, it almost certainly has a not-before time, and overflowing back to January 1st, 1970 will be before that not-before time. And so any behavior relying on that IoT device connecting to a service will fail.
Recently I brought up an emulated PPC running Mac OS 9. The included copy of Microsoft Internet Explorer couldn't connect to any site that used https -- and virtually everybody uses https these days.
I see now there are other novel ways of supporting preemption for emergency vehicles, although I’m still unconvinced that’s what our city uses as the lights often preempt several minutes in advance and from over a kilometre away.
-- fire/ems provider.
I'm assuming it's illegal to use one obviously, but I wonder what precautions are used to prevent unauthorized usage, if that can even be disclosed to the public. What's stopping the average joe from getting one from Alibaba?
There is an encoding standard for prioritization that some larger systems use, that mass transit may utilize, but can be overrode by Fire/EMS/LE.
Realtime map someone made with that: http://jouni.kapsi.fi/trevalot/
Fictional or not, cities are hyped up on 'smart infrastructure', sorry to deliver the bad news.
Trying to minimize the amount of broken code that's still running in 2038 is a big part of why people are working hard to fix the problem now.
The minimum representable date turns out to be on 1901 and zero is a valid value (1 January 1970)... I wonder what problems people with that birth date have? Similar to the person named Null, or Bobby Drop Tables?
For example, on the sensationalized "documentaries" we had leading up to Y2K, they showed a stream of appliances and gadgets that had processors in them -- hair dryers, microwave ovens, dishwashers, food processors, etc saying they all would be vulnerable. Some of these display the time, but I haven't run across a microwave yet that accepted a date input.
Wow, I knew it was approaching soonish, but that's an eye-opening way of putting it.
I wonder how many pre-2000 kernel versions are being used in devices right this moment.
That one is simple to answer: too many.
It wasn't a non-event, because it took a lot of effort to make everyone aware of the need to fix the bugs.
It's like routine maintenance except that every single device involved is going to hit problems right about at the same time, with almost no signs of trouble until the exact second it falls over. So it's not harder to fix, but if it's not fixed then it hits vastly harder.
Alternately, it will serve as a joke about how scared everyone was of breaking things written with our primitive and brittle 21st century programming techniques.
Pretty sure I made some short sited decisions as an intern, and most of that code is approaching 20 years old, and I bet it hasnt been fixed or rewritten, because for the time being, it works.
I still remember the day we woke up to multiple emails and lawsuit threats from our top player whose net worth suddenly went negative on the leaderboard.
Our players were very competitive and loved pushing the boundaries by trying to find vulnerabilities, shortcuts, etc so we assumed the worst and thought we had a bug in our system! Turned out to be our JSON parsing library was using integerValue on our NSNumber instances causing the ints to overflow. It was a tough week waiting for Apple to review the app while our players lost faith in us.
Lesson learned :)
(Luckily the player and our community was understanding and stay around)
Then I tried using git. It was badly broken: on 32-bit systems, git 2.20.1 seems unhappy with dates before 1970 or after 2038.
Will Debian 11 work after 2038 on 32-bit hardware, I wonder?
This doesn't sound as good as they wanted it to sound. I thought they were already save.
On the other hand, planned obsolescence could help and nobody is using 20 year old kernels in 2038 anymore. Hopefully.
The difficulty is that the ABI defines a 32-bit timestamp on 32-bit kernels so that can't easily be changed without breaking backwards compatibility. That's what this post is about.
So for desktops and servers this has been solved for years already. I don't know how prevalent 32-bit is in embedded versus 64-bit.
Or, now that I think of it, hopefully it won't be.
Worrying about 64-bit time overflow is like worrying about IPv6 address exhaustion.
And for those following along at home IPV6 is a 128 bit value. ~2^93 is enough to individually address every subatomic particle on Earth.
IPv6 address exhaustion is very unlikely, but it's more likely than some may have thought about.
Only 64-bit of the 128-bit address space was fully utilized, it means the utilization rate is less than 0.0000000000000000055%. And no, it's not a bug, it's a feature. The huge address space was intended to make address assignment, configuration, and routing easier. That is, in the real world, the first 64-bit part becomes the network identifier, and the last 64-bit becomes the device identifier. Ideally, everyone's home, business, institution, datacenter, etc, will get a unique, globally routable 64-bit network prefix.
So no, every subatomic particle on Earth will not get its own IPv6 address. But, everyone of the 7 billion people on Earth can have prefixes for their 263,524,915 personal computer networks.
"12 attoseconds is the world record for shortest controllable time"
After further consideration, the ultimate timestamp would be able to denote any point in time measured in Planck units (10^-44 seconds) between the beginning of the universe and its ultimate heat death in about 3 x 10^21 seconds. Therefore 218 bits should be enough for anyone.