divbzero 20 hours 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...

2
cookiengineer 15 hours 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 9 hours 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 9 hours 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 8 hours 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

madcaptenor 7 hours ago

But `ncal` does offer that option. Here's October 1582 in "Italy", which didn't exist back then:

  $ ncal -sIT 10 1582
      October 1582      
  Mo  1 18 25         
  Tu  2 19 26         
  We  3 20 27         
  Th  4 21 28         
  Fr 15 22 29         
  Sa 16 23 30         
  Su 17 24 31
France apparently took a couple months to get on board (or maybe just to find out):

  $ncal -sFR 12 1582
      December 1582     
  Mo     3 20 27      
  Tu     4 21 28      
  We     5 22 29      
  Th     6 23 30      
  Fr     7 24 31      
  Sa  1  8 25         
  Su  2  9 26         
 
`ncal -p` gives a list of the country codes it accepts. (These are current countries so it's a bit ahistorical for, say, Germany.)

Sadly they don't implement the weird thing Sweden did in the early 18th century: https://en.wikipedia.org/wiki/Swedish_calendar

sigmoid10 17 hours 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 16 hours 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)