Setting the starting date

The date here (initialised to your computer's idea of today's date) is used to find the closest full moon, from which three complete lunar cycles are then calculated and displayed. Unless today is a full moon, then the table will start at some other date than the one set at the top.
You can change the date shown and get phases of the moon for any date you choose. However no checks are currently made as to the validity of whatever you enter, so make sure you don't enter silly dates, or you will get surprising answers. The Julian date mechanism is quite robust, and will correctly extend both far into the future and way back into antiquity, but the moon algorithm may not be valid for more than a few hundred years ahead or behind the present.
Note that there is no such thing as the year zero (the Romans hadn't grasped the concept of zero) so you will get an error if you try to enter such a year. The sequence goes ..., 2BC, 1BC, 1AD, 2AD, ..., with no 0AD in the middle, but the program will correct for this by adding one to negative years. Because of changes to the calendar when things got out of step a few hundred years ago, some days don't exist at all, so you may see some surprising gaps between moon phases if you explore these periods.

Time zone corrections

The code does all its calculations in GMT, but displays the answers corrected for your local timezone. It gets this from your computer, via your Web browser, so it may not be correct. If you don't agree with the values shown at the top of the page, you can correct them and use the Recalculate button to put the new offset into effect. Better still, set your computer's date and time correctly, and tell it your local timezone. MS-Windows and MacOS have Control Panels to do this, but mainframe or workstation users will have to ask their System Administrator.
If you are West of the Greenwich Meridian, then your offset will be a negative value (it is earlier in the day in your timezone), whereas if you are East of it then your offset will be positive (it is later in the day in your timezone). Daylight savings time should be taken into account if it is in effect, by adding one or two hours to the offset.
The correct value is the one which, when added to GMT, gives your local time. Eg, EST would be Minus 5, BST would be Plus 1, for Nepal it would be Plus 5.75. All fractions are rounded to the nearest 15 minutes.

Caveats

Although the times shown may appear accurate to the last second, this is almost certainly not true and you should consult a lunar ephemeris if you need accurate timings. The values given here are only approximate and are meant to be a rough guide, not for launching moonshots.
The innacuracies are partly inherent in the method used, partly due to rounding errors, and partly the result of Javascript's occasional insistence that two plus two equals twenty-two rather than four. I have tracked down and (I think) squashed all occurrences of the latter in the code which works out the date, but so far haven't finished checking the code which calculates the time and applies the timezone corrections.

Links to related sites

Back to John's Home Page

These pages maintained by webmaster@himpi.demon.co.uk