"drift" in cycle

"You will see a slight drift in the cycle if you compare the results to other phase calculations... this is probably because of different degrees of precision among phase periods used, as well as float precision from computer to computer. It is more or less accurate and seems to always report the correct phase name."

Yet the script was a quarter-cycle off (i.e., it displayed waxing crescent when a full moon was due) when I tried it out! I found that updating the base full moon date (line 64 in moon-phase.cls.php) to a known-good value mitigated the problem, but for the value to drift a quarter cycle in four and a half years is unbelievable. I'll attempt a more thorough report on the fuzzy math when I have time. For now, here's the known-good value I used: January 3 2007 13:57 GMT.

Even that hasn't fixed it for me. That was the first thing I tried. It's still throwing waning crescent when it should be waxing crescent. I'm no php coder at all, but I've tried every tweak I can think of in the time functions (with help from the php cookbook along the way), to no avail.

The WordPress plugin version of this script works fine on another one of my sites, which may have something to do with the way the coder accesses some of the wp database info (due to the way plugins are handled in wp - that is, as part of the database structure).

However, even though my current attempt at using the script is in another blog program (the alpha version of Habari from http://code.google.com/p/habari/), trying to use the same sort of database accesses etc. don't help at all.

I wonder if a "define('') line of some sort would help? Grasping at straws, as I said, I'm no coder!

I did get the script to use the images from the wp plugin version. Makes it usable in the sidebar area of a blog setup....

Hello. I wrote this class many years ago and have since given up programming in PHP because of its many downfalls (in this case, its lack of floating point precision; see http://php.net/float ). This is why the phases are not accurate.

I could be misunderstanding floats or perhaps missing a better way to code this logic, but I would strongly suggest using a different implementation, such as http://www.calculatorcat.com/moon_phases/daily_moon_phases.phtml ... which is written in javascript and thus more portable anyway.

If anyone is still bent on doing this in PHP there may be a workaround in http://us2.php.net/manual/en/ref.bc.php , specifically http://us2.php.net/manual/en/function.bcdiv.php

Well, I did one of my usual "twinky" tweakit things. I changed

var $periodInSeconds = -1;

to

var $periodInSeconds = 2566653.861088;

which figure I derived by simple trial and error (beginning with the period in days, 29.53058867 multiplied by a full day in seconds, 86400), manipulating the result until the currently displaying moon phase agreed with the current phase as shown on the Calculator Cat QuickPhase desktop program (which I own).

Time will tell whether this progresses as it should. If it does, great. If not, then back to the drawing board....

Oh, I do note that the "days to next full moon" is changing by the 10ths exactly as it does on the wordpress install where the wordpress version is working correctly.

well it is basiclly the $periodInSeconds that doesnt get set right so if you find the place where that goes wrong then you will have found the real bug in the code

in the function getPeriodInSeconds() is where it goes wrong

wat was expexted was : 2566653.861088
and what was realy given was : 2551442.86109

a difference of : 15210.999998

what made the difference was $periodInDays = 29.53058867

which with some back calculating it came to 29.70664191(0740740740740740740741)

i also found these value 29.272 and 29.833 and a story telling it is between those two values

source : http://en.wikipedia.org/wiki/Full_moon_cycle

[quote=wiki][edit] [b]Long-term accuracy[/b]
The basic 14-lunation full moon cycle synchronization between synodic and anomalistic months is not very accurate after running a few years, so using this basic cycle to find more accurate times of the syzygies gives increasingly poorer results as time passes by. As we have seen, the Babylonian ratio of 269/251 is a much better approximation, and it spans 18 full moon cycles which are equal to 18 basic 14-lunation cycles minus 1 month. So we should correct the basic cycle (of 1 full moon cycle ~ 14 lunations) after 18 full moon cycles; with the proper epoch (starting date), this can be done by skipping the first entry of the first full moon cycle (of the next large cycle of 18 full moon cycle), i.e. use the entry with value -8 instead of 0 from the first basic 14-month table above.

When using an accumulator with the second, cyclic table above, then at the jump after 18 full moon cycles, first correct the accumulator by subtracting 8. Then apply the differential correction for the new full moon cycle phase: use the value of 18 under entry 1 in the second, cyclic table above. What happens is that we skip a value of 0 for the full moon cycle correction (under entry 0 in the first basic table above), which preserves the cyclic nature of the tables.

[/quote]