Update - PROBLEM RESOLVED!!:  Just like (almost) all frustrating problems in science using computers, this problem had a trivial, easy, and altogether obvious solution (in retrospect).  I chased the intriguing difference between the correct sideral time and the calculated sidereal time of 4 minutes, suggestively close to the difference between a sidereal day (23h 56m 4.09s) and a mean solar day (24 hours).  However, after reading up on the arcane issues in precise timekeeping, with a semi-interesting digression to learn about the 10 days missing in October 1582 at the adoption of the Gregorian calendar, I decided to recheck my program code.  Everything looked OK, and I decided to start fiddling with data types.  In VBScript, one does not declare variables as a certain type, although you can change them into certain types in the program after declaration.  I experimented with changing all my numerical variables to double-precision type, reran the program, and it now works perfectly.  So it goes...

Update (sort of):  A little context for the problem below.  We need the JD and LST for calculating which fields of the sky are visible at a given time, and for where to moon is.  We do not use these values for the time tags for the images we take, that comes directly from the computer clock, which employs synchronization software to stay accurate to less than one second.  Given that fact, we could also calculate LST directly from local clock time, rather than using JD - we had simply wanted to use JD since it seemed like the most sensible method for getting LST, and all formulas for obtaining it went though JD.  Therefore, if you have a good method for getting LST with or without using JD, send it our way!

---------------------------------------------

Here is a problem I would invite anyone to comment about.  As part of the internal programming for KELT, we need to calculate the current Julian Day (JD) along with the Local Sideral Time (LST).  I have employed two different formulas to calculate JD:

• JD = 367*Year - Int( 7*[Year + Int( [Month + 9]/12 )]/4 ) - Int( 3*[Int( [Year + (Month - 9)/7]/100 ) + 1]/4 ) + Int( 275*Month/9 ) + Day + 1721028.5 + Hour/24 + Minute/1440 + Second/86400

• a = Int( [14 - Month]/12 )

     b = Year + 4800 - a

     c = Month + 12*a - 3

     JD = Int( [153*c + 2]/5 ) +b*365 + Int( b/4 ) - Int( b/100 ) + Int( b/400 ) - 32045.5 + Day + Hour/24 + Minute/1440 + Second/86400

These formulas both appear to accurately calculate JD to at least 4 decimal places (8.6s)*(see post above).  I currently have a problem, however, accurately calculating LST.  I have so far found 2 formulas to provide LST from JD.  They are:

• a = 280.46061837 + 360.98564736629*JD + 0.000387933*( Int(JD/36525.0) )^2 - ( Int(JD/36525.0) )^3/38710000

  GMST = mod(a,360)

    LST = mod( (GMST+L), 360 )

• a = 18.697374558 + 24.06570982441908*(JD-2451545.0)

    GMST = mod( a, 24 )

    LST = mod( (GMST+L), 24 )

where GMST is Greenwich Mean Sidereal Time, and L is the Longitude of Sutherland.  The first formula calculates GMST and LST in degrees, while the second formula calculates it in hours.  In the first formula, L is expressed as negative decimal degrees (-20.810694), and in the second formula, L is expressed in negative decimal hours (-1.3873796).

The top formula comes from the website of Steve Schmitt.  It seems to give LST...almost.  It is off by about -4 minutes (giving g a value for LST 4 minutes early than the correct value).  The second formula is from a USNO website, yet it seems to provide a completely wrong answer.

As a worked example, at about 10:15pm, Sunday, September 21, 2008, the JD is 2454731.3439 and the LST is 21:42:45.  While the above formulas calculate JD correctly, the top formula gives LST = 21:38:28, and the bottom formula gives 18:56:03.

Anyway, if someone has any comments about an error in the calculations, or a suggestion for a different way to calculate LST from JD, please chime in.  And we need an algorithm that will directly compute LST from JD, not a method like "determine JD at most recent UT midnight..." since we want something that will be simple to code, check, and modify if necessary.