Comment by divbzero

2 months ago

> Note that modern compilers like gcc or clang will produce something like is_leap_year2 from is_leap_year1, so there is not much point in doing this in C source, but it might be useful in other programming languages.

The optimizations that compilers can achieve kind of amaze me.

Indeed, the latest version of cal from util-linux keeps it simple in the C source:

  return ( !(year % 4) && (year % 100) ) || !(year % 400);

https://github.com/util-linux/util-linux/blob/v2.41/misc-uti...

9 comments

divbzero

Reply
cookiengineer  2 months ago

But this is wrong and can only represent dates after the specific year when they switched from the Julian to Gregorian calendar!

For more on this, I recommend reading and implementing a function that calculates the day of the week [1]. Then you can join me in the special insanity hell of people that were trying to deal with human calendars.

And then you should implement a test case for the dates between Thursday 4 October 1582 and Friday 15 October 1582 :)

[1] https://en.m.wikipedia.org/wiki/Determination_of_the_day_of_...

  • LegionMammal978  2 months ago

    > the specific year

    The problem is, which "specific" year? The English were using "old-style" dates long after 1582. Better not to try to solve this intractable problem in software, but instead annotate every old date you receive with its correct calendar, which may even be a proleptic Gregorian calendar in some fields of study.

    (How do you determine the correct calendar? Through careful inspection of context! Alas, people writing the dates rarely indicated this, and later readers tend to get the calendars hopelessly mangled up. Not to mention the changes in the start of the year. At least the day of week can act as an indicator, when available.)

  • voxic11  2 months ago

    The full code is

       static int leap_year(const struct cal_control *ctl, int32_t year)
   {
    if (year <= ctl->reform_year)
     return !(year % 4);

    return ( !(year % 4) && (year % 100) ) || !(year % 400);
   }

    Where reform_year is the year the Gregorian calendar was adopted in the specific context specified (defaults to 1752 which is the year it was adopted by GB and therefore also the US).

    So it does account for Julian dates.

    • divbzero  2 months ago

      cal doesn’t offer an option to use the 1582 reform date, but looks like it does handle the 1752 adoption in Great Britain correctly:

        $ cal 9 1752
     September 1752
  Su Mo Tu We Th Fr Sa
         1  2 14 15 16
  17 18 19 20 21 22 23
  24 25 26 27 28 29 30

      1 reply →

sigmoid10  2 months ago

I like how the linux one is also easier to understand because it doesn't perform three sequential checks which actually invert the last two conditions plus a default return. That's the kind of stuff that can make you crazy if you ever have to debug it.

  • darkwater  2 months ago

    I wondered 3 minutes "this is not right" til I realized that

      if ((y % 25) != 0) return true;

    was actually checking for different from 0 (which in hindsight makes also sense because the century years by default are not leap unless they divide by 400)