Dear Markus, Fabian, and friends: After replicating your algorithms for createJD() and JD2Date() on a spreadsheet, and comparing these to some algorithms that I obtained from Fourmilab, I have discovered that the Julian Day that you store internally is exactly half a day higher than the astronomical Julian Day. In other words, your Julian era appears to begin at midnight on 1 January 4713 BC (Julian calendar), rather than noon on that day. What I find most remarkable about your algorithms is that they do not need to store a Gregorian epoch in order to work.
If support of the Julian calendar were all that was at stake, I would simply alter the Fourmilab algorithms for the Julian calendar to use your altered JD. But because I also want to support other calendar models that depend quite closely on the astronomical JD, and also because the adjustment of your algorithms to produce a proper JD is absurdly simple, I have decided to correct them. However: I won't send a patch for that correction alone, until I have developed and tested good Julian-calendar conversion and back-conversion functions. The reason is that Julian-calendar support will probably require some rather more extensive revision of your existing conversion code. I have also decided on a means by which to preserve "lack of precision." If I store a "format" variable that counts the actual number of provided parts of the date (1 for year only, 2 for a year and a month, and 3 for all three parts), then I can have my back-conversion functions store month and day values only when this "format" variable allows that. I'll have much more work to perform, mainly in testing my code to find out why I was experiencing repeated failures, whereas your code performs consistently well. Temlakos ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
