←back to thread

420 points gnabgib | 1 comments | | HN request time: 0.918s | source
Show context
divbzero ◴[] No.44001929[source]
> 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...
replies(2): >>44002936 #>>44003470 #
cookiengineer ◴[] No.44003470[source]
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_...

replies(4): >>44007037 #>>44007095 #>>44007164 #>>44007379 #
1. LegionMammal978 ◴[] No.44007095[source]
> 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.)