Just a friendly reminder:

We are closer to the Y2038 bug than the Y2K bug.

@GeoffWozniak @fribbledom Computer programmers, full of themselves and thinking they’re gods gift to mankind since 1948!

@thomasfuchs @fribbledom This is why computer history is so fascinating. And it's a shame it seems to be utterly neglected by educational institutions.

@thomasfuchs @GeoffWozniak @fribbledom

Well. In my case, since 1973. My name literally means "God's gift". They forgot to specify which god, though ;)

@GeoffWozniak @thomasfuchs @fribbledom To be fair, we have definitely figured out GIs. It only takes about nine months to produce a new one, followed by a three-year training period until they begin providing insight.

The real work is on cutting down that time.

@wizzwizz4 @thomasfuchs @fribbledom I don't believe that is true for a lot of cases. It is true for some.

It works decent for content recognition, but it still can't get spam right (it's okay) and it's just terrible and outright wrong with hiring, along with pretty much every other major thing.

It can be considered "working" if you see the insights based on your own and existing biases.

@GeoffWozniak @thomasfuchs @fribbledom You're talking about the models that have been trained for a decade or more, right? Those are incredibly prone to overfitting; avoid using them for anything important.

@GeoffWozniak @wizzwizz4 @thomasfuchs @fribbledom Hate to whoosh it to you, but I think they meant, like, actual H Sapiens children :blobcatcoffee:

@thomasfuchs @fribbledom Or 44 years ago, depending on which value of “cars” you use (I’m using “having on-board steering and propulsion mechanisms”).

(Of course, Morgantown PRT wouldn’t be considered “cars” by a lot of people, but…)

@funnypanja @fribbledom it's when we will run out of time and get teleported to year 1901


The UNIX timestamp is used by many computers to record the time of events. It counts the seconds that have elapsed since Jan 1st 1970.

But numbers in computers can't be arbitrarily big, because you need to designate a certain amount of memory to them. As such UNIX timestamps were defined to allocate 32 bits of information, which lets you store numbers up to 2,147,483,647.

In 2038 more seconds than that will have passed, and it could lead to problems not unlike the Y2K bug.

@fribbledom @funnypanja I've been reading a book and it's set approximately 6000 years in the future and the unix timestamp is the primary measurement of time, you have ksec, msec, gsec, etc.

It was simpler than trying to keep sync with local times.


Programmers world-wide came to same conclusion some decades ago 😂


@fribbledom @izaya ah shit, well, you better figure something out! We're all counting on you!... Literally...


Many things have switched to 64 bit time values, yes, but they're not unsigned.


@gudenau There's nothing wrong with signed values, as long as you have the bits of precision to support it. 64-bits gives you precision to measure as far back as origin of the universe, and a future wrap-around somewhere close to 150 billion years into the future.

@fribbledom @gudenau @funnypanja even signed 64 bit integers are big enough for now. 63 bits of counting seconds give us ~3x10^11 years, which is close to 21 times the current age of the universe.

So even counting milliseconds we've got plenty of numbers there.

@gudenau @fribbledom @funnypanja The 9P protocol still uses a 32-bit timestamp, but it is unsigned. So, instead of a 2038 problem, it has a 2107 problem.

@fribbledom My question is, to be answered in detail ONLY if I need to be concerned with the Y2038 bug:

What is your favourite colour?

It's a kind of teal that I associate with my pronouns at this point because of a trans Discord I'm on


Potentially yes. It's easy enough to adjust the size of a time_t (and many newer OS have started to do just that), but that could obviously also affect existing data, which would need to be converted first.

I actually think it may be a little less chaotic than Y2K was: the affected code is easier to identify here.

@fribbledom It was somewhere in the 3.x Linux kernel tree this was changed. Any code (re)compiled with the matching libc and uses the correct "time_t" type will automatically be fixed.

Similar to y2k and cobol-v1968, only software explicitly told to incorrectly use u32 will have problems internally.
(and most likely systemd *ducks-and-runs*)

@fribbledom 😬

can't wait for all of IoT devices to be transported back into 1970.

@fribbledom I was just wondering why I can't set my iPod touch (iOS 4) date beyond the year 2038! The more you know.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!