They had decades to fix this. They could have e.g. fixed this by Linux 2.0, as they broke everything.
The end result is that all sorts of systems made before now (and before it’s fixed, as it still isn’t) will never get updated and will blow up in 2038.
Items like these are why I like lobsters. Can’t imagine sending this to my friends, but here, it’s cool.
It is going to be at 2020-09-13 12:26:40 UTC.
Python:
GNU date (Linux):
BSD date (macOS, FreeBSD, OpenBSD, etc.):
All such dates (in UTC) until the end of the current century:
Specifically on Sun, 13 Sep 2020 12:26:40 UTC.
Nice, just 547483648 to go until a round number!
Tick, tock, tick, tock.
The clock is ticking. 2038 approaching.
The BSDs mostly dealt with this ages ago, but Linux is still not 2038 ready for 32bit architectures (save RV32).
This patch seems to address the issue for 32-bit Linux systems:
https://lkml.org/lkml/2020/1/29/355?anz=web
If you ignore everything else that needs to be done, sure, it does “address the issue”.
If only if solving the Y2038 problem was as easy as a single kernel patch.
Hopefully more progress will be made in the 18 years remaining.
They had decades to fix this. They could have e.g. fixed this by Linux 2.0, as they broke everything.
The end result is that all sorts of systems made before now (and before it’s fixed, as it still isn’t) will never get updated and will blow up in 2038.
an event of this magnitude happens about every 3.17 years
Good riddance to 1.5G. Here’s hoping 1.6G is a happier era!
If you’re really psyched about it, you can watch it roll over with this live clock.
I still remember the billennium.
https://en.m.wikipedia.org/wiki/Unix_time#Notable_events_in_Unix_time
Obligatory trivia that “billion” is really hard for some of us non-native speakers: https://en.m.wikipedia.org/wiki/Long_and_short_scales
E.g., a German “Billion” is 1_000_000_000_000 and not a billion, i.e. 1_000_000_000.