Just a friendly reminder:
We are closer to the Y2038 bug than the Y2K bug.
@fribbledom also we’re closer to 2070 than to the moon landing
Fuck, this one hurt.
@fribbledom otoh, self-driving cars are always two years away!
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.
@fribbledom the what
@fribbledom can u not
@fribbledom Oh god I feel old
@fribbledom what's the 2028 bug??
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.
@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.
@vertigo I guess stuff did happen before 0.
@fribbledom Oh wow, did not know that.
@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?
@fribbledom this is the one that might *actually* happen, right?
@fribbledom yay for job security in 2037! 😂
@fribbledom And this one is much more difficult to resolve
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 Why don't we start counting again from 2030?
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.
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!