[Kstars-devel] On ExtDate and ExtDateTime classes

[Pablo de Vicente]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Jason,

  I have been looking at the ExtDateTime and ExtDate classes, I admit not very 
thoroughly, and I am a bit puzzled because I do not understand how all this 
works. It seems that class ExtDate keeps the date with a long integer called 
jd, which is not the Julian Day, because it is calculated so:

int ExtDate::dayRank(int y, int m, int d)
{
        int     a_day_number;
        a_day_number = y*365 + (y+3)/4 - (y-1)/100 + (y-1)/400;
        a_day_number += dayOfYear(y, m, d);
        return a_day_number;
}

Am I wrong? On the other hand I see that functions 
ExtDate::gregorianToJulian() and julianToGregorian() are empty. I apologize 
if I am so dumb I do not see this properly.

I think it would have been better to keep the date using real julian days and 
therefore using the functions we have written in KSUtils. However this is not 
necessary and if we keep the class as it is now, we can still do two things:
 - create a KStarsDateTime which inherits from ExtDateTime as defined now and 
add some functions or/and
 - add more functions to ExtDateTime.
 
If we added these functions, we could suppress part of the functions of 
KSUtils and use for example functions like ExtDateTime.julianDay() or 
ExtDateTime.modifiedJulianDay() in a more class fashion way and without 
having to use static functions from KSUtils.

I would like to add the following functions to ExtDateTime:

ExtDateTime ExtDateTime ::setJulianDay(long double jd);
ExtDateTime ExtDateTime ::setModifiedJulianDay(long double mjd);
const long double ExtDateTime ::julianDay(void);
const long double ExtDateTime ::modifiedJulianDay(void);
const long double ExtDateTime::julianDayat0hUT(void)

furthermore, I would add the following specialized functions which may be only 
interesting to KStars. This could be accomplished by creating a 
KStarsDateTime class:

double epoch (void);
static long double epochToJd (double ep);
const QTime DateTime::GST(void);
const QTime DateTime::GSTat0hUT(void);

The latter function would require class KSNumbers, because we need the 
obliquity of the ecliptic and that is another reason for including these 
functions on a KStarsDateTime class. That reminds me that the the formula we 
use for computing the obliquity of the ecliptic is valid only for J2000 +- 
10000 years (Meeus, pag.135) and that might explain the constelation 
deformation you see for very remote epochs. 

If you agree, I can add part or all of this functionality. I think that if we 
do not want to touch the ExtDateTime and ExtDate classes as they are now,  
since they may go to KDE core or even to Qt, it is rather innocous to create 
a KStarsDateTime which includes these functions.

what do you think?.

best regards,

Pablo

PS: 
Taking profit of the previous changes we can also (I may) add the following 
functions to class GeoLocation:

QTime GeoLocation::LST(ExtDateTime & dt);
QTime GeoLocation::LSTtoUT(ExtDateTime & dt);
QTime GeoLocation::LSTat0hUT(ExtDateTime & dt);

and remove those from KSUtils.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAg5tBSItUpHl6kJERAvmtAKDswgPQ/It6o0tP+IbusATzHAgjHQCfXhn2
cnF3isxkbQT65/1IvwlqJuM=
=WjFQ
-----END PGP SIGNATURE-----