Let's not forget the stuff that'll break December 31, 2020... because it'll be day 366 (or 365, if 0-indexed). Anyone still using a Zune out there?
I have an old Zune. Going give this a try this year
2020 Leap Day Bugs
91–100 of 150 posts
Re: 2020 Leap Day Bugs
#92Earlier quoted context omitted.
It's not only about writing your own library though. For example, it's often not reading the documentation properly. In Python, if you take a datetime, and call .replace(year=X) on a datetime for Feb29, it'll throw a ValueError.
Even if you replace it with another leap year?
No another leap year would be fine. But yeah a very common (wrong) pattern is, if you want to find the same day a year in advance, is to do `d.replace(year=d.year + 1)`, and that would break on Feb 29 only, so one day every 4 years. It's a very common pattern unfortunately.
Re: 2020 Leap Day Bugs
#93Earlier quoted context omitted.
When you encounter someone saying "no one should ever", you can substitute "fewer than a half dozen groups of people should tackle this problem (in systems they want to use in production). It will take each such group a tremendous number of hours, involving a multi-year process of slowly finding edge cases and missing functionality." If that's not true, then there's room to complain, but dates and times fit the bill.…
What if people tried to speak precisely for effect instead of hyperbolically for emphasis?
Precision of understanding would go up and emotional investment in a topic would likely be more proportional to true stakes?
Sounds boring but functional.
Re: 2020 Leap Day Bugs
#94is there something special about 2020 (regarding leap years)? the rule I know is divisible by 4 && ( not divisible by 100 || divisible by 400) so 2020 is not even an edge case.
I think the answer you were looking for was, apparently NO there is nothing special about 2020 in relation to this problem. Despite the misleading use of year 2020 in the title and the title of the linked page, what is being experienced is a simple mis-coding of year+1 calculations. The title could have been,
"Leap day bugs, again! People, must we go through this every 4 years?"
So this is a crop of bugs that are either code written in the last 4 years or untested/unnoticed/unreported 4 years ago.
One of the Sprint examples (someone roaming between two cell towers and their date changing back and forth) is especially disturbing.
Re: 2020 Leap Day Bugs
#95relevant: falsehoods programmers believe about time https://news.ycombinator.com/item?id=4128208
Re: 2020 Leap Day Bugs
#96Earlier quoted context omitted.
And probably because signed integers are a default choice in certain languages and/or maybe on certain architectures. Java, for example, famously doesn't even have an unsigned 32-bit integer primitive type. (But it has library functions you can use to treat signed integers as unsigned.) Ultimately not a good design choice, but the fact that it actually wasn't that limiting and relatively few people care or notice tel…
> out of range unsigned int AFAIK, that doesn't exist? Otherwise, unsigned would also have UB?
I think he's referring to an unsigned integer value that's out of range for the signed integer type of the same width—usually a bit pattern that would be interpreted as a negative number when cast to a signed integer type, but which negative number is not defined by the C standard because it doesn't mandate two's complement representation.
Re: 2020 Leap Day Bugs
#97Earlier quoted context omitted.
And probably because signed integers are a default choice in certain languages and/or maybe on certain architectures. Java, for example, famously doesn't even have an unsigned 32-bit integer primitive type. (But it has library functions you can use to treat signed integers as unsigned.) Ultimately not a good design choice, but the fact that it actually wasn't that limiting and relatively few people care or notice tel…
> out of range unsigned int AFAIK, that doesn't exist? Otherwise, unsigned would also have UB?
I'm reading that as, the value of the uint is out of range for the int.
Re: 2020 Leap Day Bugs
#98LogRocket is reporting every date as Feb 28, 2020.
Re: 2020 Leap Day Bugs
#99So frustrating that my embedded code works without a hitch and our company is nearly bankrupt, while our bank with billions of dollars in annual profit goes offline since it cant handle leap years.
Re: 2020 Leap Day Bugs
#100Earlier quoted context omitted.
I assumed you were being precise when you asked "why can't people speak more precisely" and also when you asked "can you explain how your comment relates to mine?" I am not the person you originally responded to, fwiw, and I agree that trying to speak precisely is a useful exercise, even if I believe it is impossible except in highly formalized languages.
I wrote "What if people tried to speak precisely", not "why can't people speak more precisely".
Ah. My apologies. Hope you enjoyed the article at least.