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.
Or there's an unfinished ticket in the backlog that says "Oh gosh, let's just bodge all these values in the database and make sure we fix it by the next leap year".
Over 4 years there are a lot more apps and a lot more reliance on apps. There's lots more spaghetti out there since 2016 so more likelihood of bugs. I assume 2024 will have more.
I do wonder whether the fact that some systems aren’t really 4-digit-year compliant is making this uglier this year. I know Splunk got hit with a 2020 bug.
"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.