This "problem" was solved COMPLETELY about 2500 years ago. The Jewiah calendar is so-called "solunar"one. To maintain the Jewish festivals in the correct seasons, and to circumvent the original method of having "spotters" to identify new moons (the demarcation that defined the first evening of each month), the rabbis came up with a calculated calendar that is based on a 19-year cycle, with some years having 12 months, others with 13. The months themselves can have either 29 or 30 days. It's incredibly accurate, and has maintained solar and lunar average synch ever since! Try looking up the details! It's both fairly complex in implementation, but astoundingly simple conceptually! It actually has fewer "prototype" pages in the 19-year "perpetual" version than the present adjusted Gregorian.
@Stargzer: Beware the difference between the two definitions of Blue Moon! The newer one is two full moons in a month, the other is the third of four full moons in a season.
I think I'm on top of this -- I have no truck with the new definition -- I hold to the original definition that it's the third of four full moons in a season.
There's also the problem that the Maine Farmer's Almanac, referenced by a lot of discussions on this topic, defined the start of each season according to the Right Ascension of the Mean Sun -- an idealised, fictional Sun which moves at a uniform speed, giving seasons of equal length. By comparison, the start of the astronomical seasons are defined according to the actual position of the Sun against the fixed stars, which leads to seasons of unequal length. I'm going with the astronomers on this one.
Max said: Now I'm moving on to calculating the date of the next blue moon (watch thsi space).
Beware the difference between the two definitions of Blue Moon! The newer one is two full moons in a month, the other is the third of four full moons in a season. Also note that sometimes astronomical tables reference UTC (Uniform Time Coordinated), which is close enought to GMT for the rest of us. So something that happens in England can be on a different local date in the US (and elsewhere!).
Wikipedia has a good discussion on this topic, including the origin of the first definition by a misinterpretation of the second in a 1946 article in Sky & Telescope magazine. A later Sky & Telescope article (referenced in the WIkipedia article) goes into more detail.
@Garcia: Is the problem related with the reference day you took?
Nope -- check out the other comments to see where my problem lay.
I've since verified my algorithm (using the synodic month) for multiple reference full moons from 1900 through to 2014 -- also I've tried it for ones that started as early as 0:13 in the morning and as late as 23:18 at night (just to check that small errors didn't creap up on me) and thus far it's worked in all cases.
Now I'm moving on to calculating the date of the next blue moon (watch thsi space).
@ElizabethSimnon: the problem is that you used a sideral month instead of a lunar month (29.53059 days)
You've got it -- I was using the sidereal month with a value of 27.321661 days, when I should have been using the synodic month value of 29.530588 days.
When I was laying in bed working this through in my mind, I knew that my algorithm was being calculated correctly -- by a process of elimination I realized that the only factor remaining was the value I was using for the period of the monthy cycle, so I went back to the web and looked up "lunar cycles" and saw a bunch of entries, including the difference in the definitions of sidereal and synodic months.
I was both "high-fiving" and kicking myself at the same time :-)
Is the problem related with the reference day you took?
If the sideral month 27.321661, and if we assign a integer "label" to each full moon, there will be potential reference days that deviate from its real value. i.e. we will need to assign a real "label" to every reference full moon or, alternatively, take a a reference full moon day in which the "label" is as close to a integer number as possible.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.