How Many Thursdays? | Hacker News Reader

How Many Thursdays?

leancrew.com

42 pointsAmorymeltzer19 comments

I submitted this largely for this little nugget:

>Since every month has 28–31 days, we know that each month has four weeks plus 0–3 “extra” days. If the date of the first Thursday is less than or equal to the number of extra days, there will be five Thursdays in that month.

I definitely thought the conclusion was going to be something like: "We need to loop over every day to count Thursdays, because of calendar shenanigans in August 1632 in Russia and February 1295 in the Holy Roman Empire, which caused there to be 0 and 21 Thursdays, respectively." Maybe I've read too many "Falsehoods Programmers Believe about X" articles.

(The exceptions mentioned are made up. I don't know of any month that had a number of Thursdays other than 4 or 5.)

In Britain and the (then-future) USA, September 1752 had three Thursdays - Wednesday, September 2 (Julian) was followed by Thursday, September 14 (Gregorian), and then there was Thursday the 21st and 28th. That month had only two Sundays and two Mondays. Other countries that made the Julian-Gregorian transition at other times will have similarly short months somewhere else in their history.

There might be an instance of six of the same weekday in a month, if some area repeated the right day while moving from the Asian side of the international date line to the American side. Alaska's the only example I can find, but they also switched from Julian to Gregorian at the same time, so they had Friday, October 6, 1867 (Julian) followed by Friday, October 18, 1867 (Gregorian).

Samoa skipped a Friday in December 2011 [1]. There were 4 Fridays left so "4 or 5" still holds, but using arithmetic to calculate the number of Fridays would have yielded a wrong answer.

This is pretty uncommon with whole days so maybe less important, but thinking in this way (how can I optimize this annoying code) often leads to wrong arithmetic around hours (daylight savings and time zone changes) or seconds (leap seconds).

[1] https://www.abc.net.au/news/2011-12-30/samoa-skips-friday-in...

I generally tend to (perhaps superstitiously) do things the "slow way" like this, for exactly this reason.

This kind of thing is also generally why I don't understand people who don't like "dependencies" in general. If something requires specialized knowledge, I would much rather let the specialists work on it, than arrogantly assume I know enough to do it myself correctly.

There are (at least) two kinds of dependencies:

1. Complex libraries and mechanisms that you couldn't (or are complex enough that you wouldn't) make on your own.

2. leftpad.

The former is worth using in many situations. I would not make any kind of network protocol implementation myself in most cases because, while I can, I don't have time to do it correctly (vice hiring a proper expert or purchasing/using an expert made implementation).

The latter is the garbage that causes problems, for various reasons. The ubiquity, for instance, of this totally trivial package broke a lot of other systems when they could have been replaced with a very small (and easily shown correct) bit of your own code. The other problem is that they are opportunities for corruption of your system. The more dependencies you have (direct or indirect via transitive dependencies) the more attack surface area (poor code permitting an attack) or potential for others to insert attacking code (the code isn't just insecure, but it's actually the attack itself).

The problem with dependencies is that you start relying on Other People's Support, and that can vary from package to package.

The support you get from the Apache Foundation is going to be a lot different than the support you get from, say, a React community-maintained fork of an originally JQuery component that builds some oddly specific finicky frontend paradigm.

> If something requires specialized knowledge

This seems to be very much the point. I suspect there's actually disagreement about whether the thing actually requires specialized knowledge. If there were actually 700 days of February 1295 in the Holy Roman Empire, what are the chances that month would be handled correctly by any layer of my Thursday-counting Saas platform? A lot of times the "specialists" are just as likely to say something like "Dates before 1900 are not supported because they're too hard". And your app probably didn't care about those cases anyway.

I use fragments of this POSIX shell script for cron, to specify that I only want processing on a specific Thursday as defined by GNU date.

These were the Thursdays for July of 2021 (pick any Thursday to see them all).

    $ ./monthday.sh 7 15
    1 8 15 22 29

    $ cat monthday.sh 
    #!/bin/dash

    m="$1" d="$2" w=$(date +%u -d $m/$d) d=$(date +%u -d $m/1)

    [ $w -lt $d ] && c1=$((8 - d + w)) || c1=$((w - d + 1))

    c2=$((c1 + 7)) c3=$((c1 + 14)) c4=$((c1 + 21)) c5=$((c1 + 28))

    { date -d $m/$c5 || c5=0; } > /dev/null 2>&1

    echo $c1 $c2 $c3 $c4 $c5

My first solution in shell would have been horribly unportable across locales (though perhaps adding LC_ALL=C would fix that):

  echo $(($(cal -3|cut -c13-14|grep -cv '  ')-2))

+ cal -3 will print 3 months spanning the current date(default horizontal on most modern cal implementations).

+ Grab characters 13,14 (the Thursday column of the first month).

+ grep to eliminate blank entries

+ There is no English language month+4 digit year that will not have at least 1 character in the Thursday column, and of course the "Th" header is also there, so subtract 2 from the result

I would create a lookup table with 336 entries for every (year%28+month)

https://en.wikipedia.org/wiki/Solar_cycle_(calendar)

336 bytes. Even 168 bytes because half byte is 16 values and we need only 7, so pack two answers in one byte. Even 126 bytes if we pack blocks of 3 bits. Seem reasonable even for embedded.

How would you do that in the Shortcuts app?

I'm not familiar with Shortcuts at all, but is not this related? https://help.apple.com/workflow/#/apd142384946

There's a very quick way to figure out the day of the week for a given date (dd/mm/yyyy) using Zeller's Congruence[0]. By figuring out the day of the week for the first of the month and knowing how many days in the month (with an allowance for leap years), it's easy to then calculate the number of Thursdays.

[0] https://en.wikipedia.org/wiki/Zeller%27s_congruence

This uses the GNU version of sed and the BSD versions of everything else. Roughly: print the calendar, transpose the data, get the line with only Thursdays, count the spaces between the dates fo the Thursdays. Just realized I have a picket fence error. You can fix that. Also it's the wrong month. Also it's horribly unportable. Also it rocks.

cal | sed 1d | rs -T | grep Th | sed -e 's/$ \+$\|^Th \+$//g' -e 's/ \+/_/g' -e 's/[^_]//g' | wc -c

Hmm, thinking about this, you get the day of the week w plus the day number d of the last day of the month. If d=28, then return 4. Otherwise, assuming w=0 is Monday,¹ we'll then calculate wʹ = w - (d - 29). Rebase everything mod 7 and if dʹ ≤ 3 ≤ d, there are 5 Sundays, otherwise there are four.

⸻⸻⸻

1. If w=0 is Sunday, we'll add 6 ≡ -1 (mod 7) to w to rebase our modulo arithmetic.

Funny enough - in SQL you could just write a query if you have a standard date calendar, and I think it would be almost as fast as any solution - and really flexible for however you wanted to format.

Nice, after looking at all the other bash attempts I learned about ncal today.

ncal 09 2021 | grep "^Th" | awk -F' ' '{print NF-1; exit}'

IIRC, ISO 8601 counts weeks by counting thursdays.

Reply on news.ycombinator.com