J2000 och UNIX-time?

[Marta]

Har ett program där det krävs omvandling mellan UNIX-time och J2000. Det görs två astroomiska beräkningar. Den ena på månens upp-/nergång och den stämmer fint med expertberäknade tider. Den andra räknar på solens tider och där är avvikelse när jag använder samma omvandling som för månen. Används däremot en magisk harrang som vill ha upphackad tid som indata så stämmer den perfekt. Skillnaden mellan de två J2000 är två dygn.

Enligt uppgifter på nätet är offset -10957.5 dygn. Denna är vad månberäkningen använder och måste vara rätt. Annars hade måntiderna blivit totalt blaj. Harrangen i originalet av solprogrammet genererar J2000 som om ofset var -10955.5 dygn.

Här är harrangen. 0.5 skall adderas för J2000.
#define days_since_2000_Jan_0(y,m,d) \
(367L*(y)-((7*((y)+(((m)+9)/12)))/4)+((275*(m))/9)+(d)-730530L)

Gör denna harrang fel och i så fall, varför vill solprogrammet ha ett förmodat trasigt värde på tiden? Kan det vara en gammal algoritm som kompenseras för någon typ av irregularitet med skottdagar e.dyl.? Skulle vilja reda ut avvikelsen innan jag accepterar att det bara är så.

Coden kommer härifrån:
http://www.stjarnhimlen.se/comp/sunriset.c

[Icecap]

Jag faller direkt på: days_since_2000_Jan(y,m,d).
y, m & d är ju INTE dagen datum men dagar sedan 2000-01-01 00:00:00.

Iaf. efter namnet på funktionen.

[Marta]

Det är just det som är J2000. Egendomligt nog är nollpunkten kl.12:00 denna dag. Klockslaget anges som decimaler där det förekommer. J2k är en efterföljare till JD som räknas från jättelängesedan.

[rvl]

Det är sen gammalt att jd byter mitt på dagen, så det inte blir något byte mitt i nattliga stjärnobservationer.

[Marta]

Har tänkt samma tanke, men det som är mitt på dagen vid 0 graders lonitud, är ju mitt i natten vid 180 grader. Alla kan inte alltid vara nöjda.

Men vad förklarar de två dygnens fel mellan det som uppenbarligen är det rätta och det som solprogrammet använder?