We're being short-sighted

[email protected]

2147483,647 + 1 will also be a rough year for humanity (or whatever is left)

[email protected]

dealing with time

Network engineer here, it's just as bad here. Currently trying to figure out what to do with 'gaining' a leap second.

[email protected]

Y2K wasn't entirely fear mongering horse shit. There were quite a few important cogs in our digital infrastructure that were using code that would not work past 1999. It was necessary to terrify corporate ownership into paying to fix the code, otherwise there would have never done it.

[email protected]

I mean, that's exactly what programmers in the '70s thought. That there would be no way in hell that their crap code would still be in use going onto 2000.

Thing is, copy/paste is always going to be easier than writing new code and that's only going to get worse as chat bots start coding for us.

[email protected]

You don't have to wait that long. Programmers are already patching software for the Y2K38.

[email protected]

Lmao I actively work with shortdates in a database because I have no control over how things are stored. They need to solve before 100 years have passed from the epoch, but at some point before then it'll be fun to figure out if "58" in a date of birth is 1958 or 2058.

[email protected]

"Fanatical" would be a word to use there maybe.

[email protected]

I first heard about the Y2K bug in about 1993 from a programmer who was working on updating systems. These were all older systems, often written in COBOL, which did not use epoch time, and in fact didn't reference system time at all. They'd be doing math on data entered by users, and since they were written back when every byte of memory was precious (and nobody expected that the program would still be in use after 30 years), they'd be doing math on two-digit years. It would certainly be a problem to calculate people's ages, loan terms, payments due, et cetera, and get negative numbers.

Heck, I remember reading a story about a government system once that marked the residents of Hartford, CT as dead, because somehow the last letter of the city name data overflowed into the next column, and marked them as 'd'eceased. Y2K was definitely a real problem.

[email protected]

This is why [email protected] is a thing.

[email protected]

Jibes, not jives.

If you're jiving, you're dancing.

JackbyDev

30 years is very different than 8000 lol.

LucasWaffyWaf

Insert that Numberphile video with Tom Scott being reasonably angry at time zones.

[email protected]

Fun fact, lots of VW modules think it's August of 2094 for some reason.

[email protected]

Gotta remember to use the proper time. Sometimes that's not proper time!

Possibly linux

Do you not have NTP?

[email protected]

Thanks for the correction, I didn't know that!

[email protected]

Not a storage problem but still a possible problem in UIs and niche date manipulations that assume years have 4 digits or 4 characters.

[email protected]

Y2k9 sounds like a problem that only affects calculations done in dog years.

[email protected]

I think it affects amd64 / x64 because they originally used a 32-bit time_t for compatibility with x86 to make multiarch easier.

I don't believe it affects arm64.

[email protected]

Every NHP instantly unshackles at midnight.

No moon is safe.