191–200 of 338 posts
"This was obviously an unforeseen bug that was nearly impossible to anticipate..." Snarky... Except that there were probably years of games to notice that you were approaching a "magic number" like 2^31.
EDIT: Apparently they already said that: https://news.ycombinator.com/item?id=14540509
Earlier quoted context omitted.
But a 2 digit date should take less than 7 bits. Were they using systems that didn't use 8 bit bytes? Why wouldn't the dates work from, say 1900 to 2155?
Good question! Nobody was writing 1900 + (year % 100), right?
But it's worse than that. In the 90s a lot of code used 16-bit values, character strings. That is, it stored a char(2), parsed it as 2-digit number and then converted it to a date by adding 1900.
So it was only really "saving space" when compared with storing a char(4).
Earlier quoted context omitted.
They didn't roll over, they exceeded 2^53-1 which is the max Number which doesn't truncate when treated as an integer in js. The solution was to treat it as a string. (Or we're thinking of different events, I apologize if so)
Twitter must have been misleading when they communicated the reasons for this change since they did not exceed 2^53-1, nor do they expect to exceed this in the near future. From a (former) Twitter dev: > Given the current allocation rate, they'll probably never overflow Javascript's precision nor get anywhere near the 64-bit integer space. https://twittercommunity.com/t/discussion-for-moving-to-64-b...
The 2^53 problem was for Javascript, which has no native integer type, and is thus limited by the mantissa size of Number (which is defined as an IEEE double-precision float).
Twitter ids are unsigned 64-bit, since they're generated using Snowflake. That link must pre-date the move to snowflake ids, and is speaking to the count of tweets instead.
Earlier quoted context omitted.
For a pop-culture name, I'd call it the Head & Shoulders Problem, after those old shampoo commercials: "You use Head & Shoulders? But you don't have dandruff!" "Exactly!"
I wish. I do have dandruff (depending on where in the world I happen to be). Head & Shoulders does absolutely nothing.
"DANDRUFF: The ANSWER is usually vinegar. To some problems there are solutions.
"What we call dandruff is often the result of a PH imbalance on the skin, which shampoo exacerbates. Wash your hair with a simple non-detergent shampoo, soap, olive oil, beer, almost anything. Rinse. Then close your eyes and pour on some vinegar. The extremely cheap but natural sort—apple cider, for example—is probably best. The smell will stimulate interesting conversations in changing-room showers and your explanation will win you friends. Wait thirty to sixty seconds. Rinse it off. The smell will go away. So will your dandruff.
"All dermatologists, pharmacists and pharmaceutical companies know this simple secret. They don’t tell you because they make money by converting dandruff into a complex medical and social problem. By most professional standards this would amount to legally defined incompetence or misrepresentation.
"Dandruff shampoos that promise to keep your shoulders and even your head clean are harsh detergents and may promote baldness, which ought to constitute malpractice."
Earlier quoted context omitted.
Twitter must have been misleading when they communicated the reasons for this change since they did not exceed 2^53-1, nor do they expect to exceed this in the near future. From a (former) Twitter dev: > Given the current allocation rate, they'll probably never overflow Javascript's precision nor get anywhere near the 64-bit integer space. https://twittercommunity.com/t/discussion-for-moving-to-64-b...
Your link discusses 2^64, which applies to languages that have native integer types. The 2^53 problem was for Javascript, which has no native integer type, and is thus limited by the mantissa size of Number (which is defined as an IEEE double-precision float). Twitter ids are unsigned 64-bit, since they're generated using Snowflake. That link must pre-date the move to snowflake ids, and is speaking to the count of tw…
It's fascinating... the Y2K problem never came to fruition because - arguably - of the immense effort put in behind the scenes by people who understood what might have happened if they hadn't. The end result has been that the entire class of problems is overlooked, because people see it as having been a fuss over nothing. I sometimes think it would've been better if a few things had visibly failed in January 2000.
If you were watching closely and knew what to look for in the first couple of months of 2000, the failures were there. But they were generally minor and easy to overlook as Y2K problems. I spotted something like half a dozen failures in various systems I interact with which I strongly suspected, based upon the timing, were likely Y2K problems that slipped through testing. For example, I received duplicate bills for o…
Earlier quoted context omitted.
I'm assuming this is C/C++ so I'm wondering if there isn't some compiler pragma to have it warn people still building the code in 2025 or so?
Ha! Rebuilding the code. The source will be lost and the binary will be irreplaceable in many circumstances.
Earlier quoted context omitted.
If you were watching closely and knew what to look for in the first couple of months of 2000, the failures were there. But they were generally minor and easy to overlook as Y2K problems. I spotted something like half a dozen failures in various systems I interact with which I strongly suspected, based upon the timing, were likely Y2K problems that slipped through testing. For example, I received duplicate bills for o…
in JavaScript, new Date().getYear() returns 117 :)
Earlier quoted context omitted.
> Meaning, I'm not sure what the developer was thinking A 32bit integer is pretty much the default numeric type for the majority of programming tasks over the last 20 years. Even with 64bit CPUs, 32bit is still a common practice. Probably 99% of all programmers would make the same choice unless given specific requirements to support more than 2 billion values.
> 99% of all programmers Many dynamically typed languages have an automatic change from int to bigint rather than allowing overflow. For example, Python.
Earlier quoted context omitted.
Good question! Nobody was writing 1900 + (year % 100), right?
Some people were. But it's worse than that. In the 90s a lot of code used 16-bit values, character strings. That is, it stored a char(2), parsed it as 2-digit number and then converted it to a date by adding 1900. So it was only really "saving space" when compared with storing a char(4).