I wouldn't call this an explanation, but it's something like one.

Starting with March, the number of days in each month follows this pattern: 31, 30, 31, 30, 31 / 31, 30, 31, 30, 31 / 31, (28 or 29). You could look at it as three sets of (31, 30, 31, 30, 31), with the last set truncated at the end of February. Advantages of looking at the calendar this way, in terms of calculating which day of the year corresponds to a particular month and day, are:

- The number of days in each month follows a simple pattern, and
- The oddity, February, is at the end of the list, where it requires no special treatment beyond "% 365."

This code

`(month + 9) % 12`

yields a number between 0 and 11, inclusive, with zero for March, 9 for December, 10 for January, and 11 for February, so it's function is to realign the months starting with March, to take advantage of 11 months of regularity. 30.6 is the average number of days in each group of five months, so multiplying by that number yields an estimate of the "ordinal date" of the first day of each month. That figure isn't precise, though, and it needs some adjustment. Looking at adding 58.5 as two separate operations - adding 0.5 and adding 58 - then adding 0.5 adjusts the number so that taking the int() function yields the proper ordinal date for the first day of the month. Adding 58 - the ordinal date of February 28 - adjusts for the fact that we temporarily treated March 1 as the first day of the year. Taking modulo 365 accounts for the fact that the calculation yields ordinal dates for January and February that are bigger than 365.

Voila!

You'll note that the calculation doesn't do anything for leap year - the year doesn't figure in to the formula, and it gives the same result for Feb 29 as for March 1. To be general, it needs to know the year and how to tell if it's a leap year, and make an adjustment for ordinal dates bigger than 58.

There's some hand-waving in that description above - particularly with regard to adjusting an estimate of the ordinal date by adding 0.5. I don't know why that works, but I suspect that it's largely because the size of the pattern - five elements - is small, and because the elements only differ by 1. But I'm not sure, and I don't want to do the work to figure it out. Calendar calculations are can be ferociously non-intuitive - otherwise, the Gregorian calendar would have been developed in ancient Mesopotamia, and we'd call it the Babylonian calendar. That, and they've usually been worked out long ago by someone who cared a lot more about them than I do. It's worth noting that the formula works with constants in a small range around 30.6, and around 58.5.

If you're hoping that you'll be able to see how this formula was derived, you may want to give that up. My guess is that this formula was developed at least in part by laborious trial-and-error. Unless you're eager to learn how to manipulate the calendar for your own edification, you'll be well-advised to be satisfied with a general understanding of why this calculation works, and move on to something you really like.