Excel incorrectly assumes that the year 1900 is a leap year - Microsoft 365 Apps
learn.microsoft.com
Explains why the year 1900 is treated as a leap year in Excel 2000. This article outlines the behaviors that occur if this specific issue is corrected.
  • Lvxferre [he/him]@mander.xyzEnglish
    9·
    15 days ago

    My question is, why did Lotus 1-2-3 have this bug?

    Because, seriously, even the Gregorian formula is simple:

    if year % 400 == 0; then leap = yes
  elif year % 100 == 0; then leap = no
  elif year % 4 == 0; then leap = yes
  else leap = no

    Sure, you’re running three tests instead of one, but with nested if’s you could make so most years are only tested once, like this:

    if year % 4 == 0; then
  if year % 100 == 0; then
    if year % 400 == 0; then leap = yes; else leap = no
    else leap = yes
  else leap = no

    Sure, it’s dirty but if you got it right it’s set up and forget about it.

    • Peer@discuss.tchncs.deEnglish
      2·
      14 days ago

      Probably in the time lotus was released people would use it for relatively simple calculations involving dates that would not go that far back. So this bug would not be a problem for those uses and go undetected for some time. Or maybe it even was a deliberate choice to improve performance since the creator would consider it unlikely to use dates decades away.

      • Kairos@lemmy.todayEnglish
        2·
        14 days ago

        Much more likely : they just had a %4 and only added the %100 case when they tested dates with the year 2000. What about 1800? Can someone test this?