No, the multiplier should not be 366. If playing with floating point and setting a suitable year zero, it should be 365.2425 since that is the result of:
365 (the standard year)
+ 0.25 (1/4 = normal leap year rule)
- 0.01 (1/100 = centuries are not leap years)
+ 0.0025 (1/400 = 1600, 2000, 2400, ... are centuries but still leap years)

In this case, there is an add for the 1/4 rule.
When the algorithm don't need to support as early as year 1900 or as late as 2100, then the 1/100 and 1/400 rules can be removed giving simpler code in an embedded product (while introducing a "y2k" error).

So the simplification then is a multiplier of 365 (the best we can do with integers) and a check how many 4-year cycles extra to compensate for the 366th day of the leap years.

The difference compared to the standard Unix implementation (if we ignore the covered range) is that the Unix functions represents the current year as 112 since the tm.tm_year field is set to year-1900.