Everyone knows that counting Chuck's knuckle sandwich beats mere poetry any day of the week month..
If you can't get that to compile and run (like the poetry), then read on.
Without regex and minus 2 modulo remainder operations, also without leap-year problems or the Date-object.
Although javascript's Date object covers approximately 285616 years (100,000,000 days) on either side of January 1 1970, I was fed up with all kinds of unexpected date inconsistencies across different browsers (most notably year 0 to 99). I was also curious how to calculate it.
So I wrote a simple and above all, small algorithm (easily beating James' answer) to calculate the correct (Proleptic Gregorian / Astronomical / ISO 8601:2004 (clause 4.3.2.1), so year 0 exists and is a leap year and negative years are supported) number of day's for a given month and year.
It uses the short-circuit bitmask-modulo leapYear algorithm (slightly modified for js) and common mod-8 month algorithm (again modified to obtain the shortest path).
Note that in AD/BC notation, year 0 AD/BC does not exist: instead year 1 BC is the leap-year!
IF you need to account for BC notation then simply subtract one year of the (otherwise positive) year-value first!! (Or subtract the year from 1 for further year-calculations.)
Note, months must be 1-based (as the question asked for)!
Note, this is a different algorithm then the magic number lookup I used in my Javascript calculate the day of the year (1 - 366) answer, because here the extra branch for the leap-year is only needed for February.
EDIT (-history):
I lifted my modified mod8 month algo
return(m===2?y&3||!(y%25)&&y&15?28:29:30)+(m+(m>>3)&1); //algo 1
to the ternary and removed the now un-needed outer parenthesis (good call, TrueBlueAussie):
return m===2?y&3||!(y%25)&&y&15?28:29:30+(m+(m>>3)&1); //algo 2
After severe testing this turned out to be the fastest algo (thanks TrueBlueAussie for the tests to which I chipped in for the caching jsperf setup). We guess the reason that this is faster then my (shorter and seemingly faster) algo 3 (the magic number bitwise lookup below), is that modern browsers can probably pre-optimise the constant bitshift in m>>3.
I figured.. well.. "and why again didn't I just do?:"
return m===2?y&3||!(y%25)&&y&15?28:29:30+(5546>>m&1); // algo 3
It uses a a 'magic number' to do a simple bit-wise lookup of offsets:
DNOSAJJMAMFJ* = Months (right to left)
CBA9876543210 = Month === bit position in hex (we never use pos 0: January is 1)
1010110101010 = offset from 30 = binary === 5546 decimal
13 bits is less than 31 bits, so we can safely save another character on the bitshift instead of >>> (as we don't need to force unsigned 32 bit).
That eliminates one memory-call (var m), one addition and one precedence! (and it's one char shorter)
One would think that: obviously these 3 extra optimizations beat my first/second algo (which as TrueBlueAussie commented, was already the fastest)...
But as I already mentioned, it turned out that this (algo 3) is not faster on modern browsers (I know, rather unexpected), we think it is because the engine can no longer optimize the bitshift.
I'll leave it here, maybe one day it will be faster, who knows..
As it turned out my algo 2 was the fastest after-all (except TrueBlueAussie's full 2D array of-course, although that takes quite some more memory and still requires a fast algo to build it client-side), I followed TrueBlueAussie's advice to revert my answer to using my algo 2.
Still I had a blast collaborating and am grateful for the incentive to revisit my answer !
