[Kstars-devel] On ExtDate and ExtDateTime classes

[Jason Harris]

Hi Pablo,

On Monday 19 April 2004 02:26 am, Pablo de Vicente wrote:
>   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:

Looks like you are right, the dayRank() function is not the Julian Day, it is 
a count of the number of days since Jan 1, 0001.  This doesn't affect the 
internal performance of the class AFAICT (just don't use dayRank() and expect 
the Julian Day).  

Anyway, this should be fixed.  We should replace dayRank with a jd() function 
that computes the actual Julian Day instead.  

> 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.
>
Yes, these functions don't exist yet.

> 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.
>
This is a very good idea.  I'll fix the problems with ExtDate and then we can 
define a KStarsDateTime class that replaces a lot of the functions in 
KSUtils, as you suggested.

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

Actually, maybe it's time to rethink KSNumbers.  Since it is basically a 
collection of time-dependent quantities, it would make sense to just add them 
to KStarsDateTime as well.  The class could internally keep track of how 
often each quantity should be recomputed, and how long it's been since the 
last update.  Much better than the current code, where KStarsData has to care 
about updating the KSNumbers values.

> 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.
>
Nope, that's a feature, not a bug!  The distortions are caused by the proper 
motions of the stars.  Some stars with high proper motion (e.g., Arcturus) 
move tens of degrees when the date is set to +- 50000!

> what do you think?.
>
Great ideas, thanks for taking a look at the code!  I'll work on fixing up 
ExtDate and friends.

> 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);
>
Great!

Jason
-- 
-------------------------------
KStars: KDE Desktop Planetarium
http://edu.kde.org/kstars