Forum > Ported from Delphi/Kylix

(SOLVED) tmoon_laz bug

(1/2) > >>

Hello Folks --

I am a novice Pascal coder working in Windows 10, Lazarus v 2.0.6, FPC v 3.0.4.  I plan on writing an application for which the Laz package called "delphimoon" (tmoon_laz.lpk) is perfect for my use.  The original package was written for Delphi by Andreas Hörstemeier.  I downloaded from this site [] the latest available version (The latest I could find, 13-Feb-2018, which includes a translation from Delphi to Lazarus/FPC).

Before using the package in my application, I compiled and began testing the demo "NewMoonTool".  I think I discovered a bug in the demo in the calculation of "Sun Transit" for certain date/location combinations that I have not been able to track down.  Can anyone find the problem and provide a fix?

Here is the issue:
Package:  tmoon_laz.lpk
Application:  "NewMoonTool" or moon.pas
Example Location:  W 77° 0' 0",  N 39° 0' 0"
Example Dates:  2019 Dec 7 through 10

ERROR:  Sun transit displays "---", should be approx "17:00 UTC"

Most other Date/Location combinations produce correct results.
(There may be other Date/Location combinations that fail.)

Any assistance would be greatly appreciated.

You should report that bug with a description and minimum compilable project showing the error to the bugtracker. What you can do, is to try to debug a little. Like searching for a location of those --- in package units, looking at code that executes before that, and putting some breakpoints in order to try to understand why some dates produce correct results and some produce '---' string results. Hopefully that would lead to a bug fix which could lead to your first Lazarus patch. Or... you can just sit and wait with your fingers crossed in a hope that package maintainer will see your forum message.

What did you do with the NewMoonTool to get the error? As far as I can see the location is determined by the selection of cities, there is no way to enter gps coordinates directly.

Ok - this code reproduces the issue:

--- Code: Pascal  [+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i < x.length; i++) { x[i].style.maxHeight='none'; x[i].style.height = Math.min(x[i].clientHeight+15,306)+'px'; x[i].style.resize = "vertical";}};} ---program Project1; uses  SysUtils, moon; const  lon = 77.0;  lat = 39.0;var  dt: TDateTime; begin  dt := EncodeDate(2019, 12, 7);  WriteLn('   Sun rise: ', FormatDateTime('yyyy-mm-dd hh:nn:ss', Sun_Rise(dt, lat, lon)));  WriteLn('Sun transit: ', FormatDateTime('yyyy-mm-dd hh:nn:ss', Sun_Transit(dt, lat, lon)));  WriteLn('    Sun set: ', FormatDateTime('yyyy-mm-dd hh:nn:ss', Sun_Set(dt, lat, lon)));   ReadLn; end.

If this is the astronomical New Moon, i.e. relative to the centres of the Earth, Sun and Moon, and if the timing is UTC, then I don't even see why the location is relevant.

If on the other hand it's related to observation of the New Moon to determine the start of the Jewish month, or is for eclipse calculations... can't you find something easier to torture yourself with? :-)

I've done a bit of this stuff (transcribing code which I think ultimately originated from Meeus). One of the problems was that the maths was sufficiently hairy that the results were platform specific... not grossly so, but things like a seasonal offset of ~3 mins for Sunrise/Sunset after correction for refraction etc.


Found a fix for the bug.  There appears to be a problem with the default version of the function "Calc_Set_Rise" (or one of its sub-functions) in Unit "moon".  When I added the directive (*$define meeus *) to Unit moon, the problem went away.  I did not investigate any further.


[0] Message Index

[#] Next page

Go to full version