NavList:

Sean, it's quite possible that someone got in there to fix it after they learned that it was broken. That's how incompetent coders work. Why expend any effort getting it right the first time? Fake it til you make it! Someone else will let you know if your code is broken, and then you get paid anyway. :)

But if you want to experiment, you can still break it. Easily! Try July 4, 1776. Can't be entered, right? WHY?? Why would a Julian date calculator be limited that way? The answer is plain and simple: poor design. Someone decided to limit input dates to the period 1800-2050 because previous ephemeris data carried those limits, even though they are completely irrelevant to a calendar calculation. And then, hey look, did you notice there's a selector for "AD" or "BC"? :)

And it works! There's no problem entering July 4, 1976 BC in their tool as it stands. The tool will happily calculate Julian dates for 2.5 centuries of AD dates and the mirror image: 2.5 centuries of BC dates. That's not a feature. It's a bug in the design. But you can circumvent the poor coding on the data input page by examing the URL that's fed to the server (the idea that this code runs server side is also absurd, but never mind that for the moment). Follow this modified link:
   https://aa.usno.navy.mil/calculated/juliandate?ID=AA&date=1776-07-04&era=AD&time=00:00&submit=USNO+Coders+Suck
Please note that I have "adjusted" the text in the "submit" field to illustrate that it is superfluous. By the way, you will notice that the order of the date elements in the URL parameters is yet again different from the entry page. They're just asking for errors.

Frank Reed
Clockwork Mapping / ReedNavigation.com
Conanicut Island USA