Version: 1.0 (using KDE KDE 3.2.1) Installed from: SuSE RPMs OS: Linux My computer is normally offline and doesn't do particularly accurate timekeeping--it gains 10 seconds/day. It compensates by running ntpdate when it goes online, resulting in the system time frequently being set back by a second or more. Kstars responds by advancing the date one day. I am aware of potential problems with ntpdate and that solutions are possible--I'll have to work on that--but I thought you would want to know how it affects kstars.
On Sunday 27 June 2004 03:41 pm, rhardy@visi.com wrote: > My computer is normally offline and doesn't do particularly accurate > timekeeping--it gains 10 seconds/day. It compensates by running > ntpdate when it goes online, resulting in the system time frequently > being set back by a second or more. > > Kstars responds by advancing the date one day. > Can you be more specific? KStars should only care what your system clock is when it first starts up, or if you explicitly invoke the "set time to now" action. Are you saying that running ntpdate causes KStars to spontaneously change its internal date forward one day? Or does the date advance happen when you start KStars, after having run ntpdate? thanks, Jason
Running ntpdate causes Kstars to spontaneously change its internal date forward one day, as shown by the time info box. The date command can do the same thing (must be run as root). Run " date --set='-2 seconds' ". The time info box will pause for a couple of seconds, then advance one day. This involves the system time as maintained by the Linux kernel, not the PC hardware clock which is ignored by Linux under most circumstances. Jumping the system time is a recognized bad thing, as it can cause confusion in programs that depend on fine grained reading of filesystem mtimes, for instance. So I am trying to fix it. ntpdate will gracefully adjust the time if the adjustment is less than 0.125 seconds, otherwise it rudely steps it. I'm looking at "man adjtimex" for a solution. Other docs are "info coreutils date", "man hwclock" and the ntpdate doc which is part of the xntp package.
CVS commit by harris: Probable fix of bug #84117 ("date jumps forward when system clock is set back"). KStars keeps time by counting the elapsed milliseconds since an arbitrary moment in the system time called "sysmark". This is matched by a corresponding marker for the simulation clock called "julianmark", which was the exact simulation time at the moment that the system time was sysmark. So, at any moment, the simulation time is simply "julianmark + scale * elapsed", where "scale" is the clock scale (1.0 for real-time), and elapsed is the elapsed time since sysmark according to the system clock. Because the elapsed time is stored as a QTime, it cannot record time for more than 24 hours (after that long, it resets to 0 hours). We had accounted for this by advancing the date by one day when we detected that the elapsed time since sysmark had shrunk, because the only situation we'd thought of where this would occur, is when the elapsed time wrapped back to 0 after 24 hours. The bug reporter found another situation where the elapsed time can shrink (i.e., if the unix clock is set back while KStars is running). So, we now simply reset sysmark and julianmark whenever the elapsed time has shrunk. This properly accounts for both situations. You may see a slight "hiccup" in the time box when reseting the time, but it immediately recovers. Thanks very much for noticing and reporting this subtle bug! CCMAIL: 84117-done@bugs.kde.org CCMAIL: kstars-devel@kde.org M +27 -2 ksnewstuff.cpp 1.5 M +4 -4 ksnewstuff.h 1.6 M +7 -4 simclock.cpp 1.21 --- kdeedu/kstars/kstars/ksnewstuff.cpp #1.4:1.5 @@ -20,11 +20,14 @@ #include <kapplication.h> +#include <kaction.h> #include <kdebug.h> #include <kglobal.h> #include <kstandarddirs.h> #include <kdirwatch.h> +#include <kprogress.h> #include <ktar.h> #include <qdir.h> -#include <kaction.h> +#include <qcursor.h> +#include <qregexp.h> #include "ksnewstuff.h" @@ -72,6 +75,19 @@ void KSNewStuff::updateData( const QStri qd.setFilter( QDir::Files ); + //Show the Wait cursor + ks->setCursor(QCursor(Qt::WaitCursor)); + + //Handle the Steinicke NGC/IC catalog if ( qd[0].contains( "ngcic" ) ) { + //Build a progress dialog to show during data installation. + KProgressDialog prog( 0, "newstuffprogdialog", + i18n( "Please Wait" ), i18n( "Installing Steinicke NGC/IC catalog..." ), false /*modal*/ ); + prog.setAllowCancel( false ); + prog.setMinimumDuration( 0 /*millisec*/ ); + prog.progressBar()->setTotalSteps( 0 ); //show generic progress activity + prog.show(); + kapp->processEvents(100); + //First, remove the existing NGC/IC objects from the ObjectNameList. for ( DeepSkyObject *o = ks->data()->deepSkyList.first(); o; o = ks->data()->deepSkyList.next() ) { @@ -109,4 +125,11 @@ void KSNewStuff::updateData( const QStri //Handle the ephemerides if ( qd[0] == "asteroids.dat" || qd[0] == "comets.dat" ) { + //Build a progress dialog to show during data installation. + KProgressDialog prog( 0, "newstuffprogdialog", + i18n( "Please Wait" ), i18n( "Installing comet and asteroid ephemerides..." ), true /*modal*/ ); + prog.setAllowCancel( false ); + prog.setMinimumDuration( 50 /*millisec*/ ); + prog.progressBar()->setTotalSteps( 0 ); //generic progress activity + //First, remove the existing asteroids and comets from the ObjectNameList. for ( SkyObject *o = (SkyObject*)(ks->data()->asteroidList.first()); o; o = (SkyObject*)(ks->data()->asteroidList.next()) ) { @@ -129,6 +152,8 @@ void KSNewStuff::updateData( const QStri ks->data()->readAsteroidData(); ks->data()->readCometData(); - } + + //Restore arrow cursor + ks->setCursor(QCursor(Qt::ArrowCursor)); } --- kdeedu/kstars/kstars/simclock.cpp #1.20:1.21 @@ -63,8 +63,11 @@ void SimClock::tick() { if (mselapsed < lastelapsed) { // The sysmark timer has wrapped after 24 hours back to 0 ms. - // Reset our JD marker by Scale number of days. - julianmark += 1.0 * Scale; - } + // Reset sysmark and julianmark + julianmark = UTC.djd(); + sysmark.start(); + lastelapsed = 0; + } else { lastelapsed = mselapsed; + } long double scaledsec = (long double)mselapsed * (long double)Scale / 1000.0;