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
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