DriftingDateTimeSingleton Class Reference

#include <DriftingDateTime.h>

Inheritance diagram for DriftingDateTimeSingleton:

Collaboration diagram for DriftingDateTimeSingleton:

Public Slots
void	setDrift (qint64 ms)
	Set the drift.
void	onPlumbingCompleted () const
	Emits to the driftChanged signal (as per TwoPhaseSignal contract).
Public Slots inherited from TwoPhaseSignal
virtual void	onPlumbingCompleted () const =0

Signals
void	driftChanged (qint64 new_drift) const

Public Member Functions
qint64	drift () const
	Retrieve drift, in milliseconds.
QDateTime	currentDateTimeUtc () const
QDateTime	currentDateTimeLocal () const
qint64	currentMSecsSinceEpoch () const
qint64	currentSecsSinceEpoch () const
Public Member Functions inherited from TwoPhaseSignal
	TwoPhaseSignal ()
	This is a humble helper class for Qt signals and slots when this mechanism is also used to initialize the data. In that case, we first do the "plumbing" phase, where signals and slots are connected as appropriate. After that has been completed, signals are to be sent in a volley so that an required initial values are being set.

Static Public Member Functions
static DriftingDateTimeSingleton &	getSingleton ()
	Get the singleton instance.

Detailed Description

JS8Call allows the user to manipulate the clock.

One intention is: If a QSO partner's clock is off too much, we can set our clock to correspond to that partner's clock. This increases the probability of successful decodes on both sides.

Alternatively, we may not be able to set our own computer's clock with appropriate precision. If so, we can manipulate our JS8Call-internal clock, e.g., based on incoming JS8 signals, to fit other folks' clocks.

There is only one, central clock for the entire application.

The manipulated clock is ubiquitously used throughout JS8Call. This includes timestamps logged to ALL.TXT or via Qt logging. This makes it easier to judge, especially when reading the Qt logs, whether JS8Call's timing is as it should be.

There is exactly one object of class DriftingDateTimeObject (singleton pattern).

Drift specified as a qint64 is always in ms. A positive drift means that the JS8Call internal clock is that many milliseconds later than the system clock, a negative drift that many milliseconds earlier.

This functionality is (intended to be) thread-safe, with the exception of the setDrift(), which must be called by the same thread that originally constructed the object. If you want to make sure this is not violated, send the new drift value as a signal.

Member Function Documentation

currentDateTimeLocal()

QDateTime DriftingDateTimeSingleton::currentDateTimeLocal ( ) const

inline

Retrieve drifted "now" as local time.

Here is the call graph for this function:

currentDateTimeUtc()

QDateTime DriftingDateTimeSingleton::currentDateTimeUtc ( ) const

inline

Retrieve drifted "now" as UTC.

Here is the call graph for this function:

currentMSecsSinceEpoch()

qint64 DriftingDateTimeSingleton::currentMSecsSinceEpoch ( ) const

inline

Retrieve drifted "now" as milliseconds since epoch.

Here is the call graph for this function:

Here is the caller graph for this function:

currentSecsSinceEpoch()

qint64 DriftingDateTimeSingleton::currentSecsSinceEpoch ( ) const

inline

Retrieve drifted "now" as seconds since epoch.

As we found out experimentally, QDateTime does not round, but truncates. So we do that, too. In other words, the number returned is the number of fully elapsed seconds since the epoch.

Here is the call graph for this function:

drift()

qint64 DriftingDateTimeSingleton::drift

(

)

const

Retrieve drift, in milliseconds.

Retrive drift, in milliseconds.

Positive values indicate the drifted clock is behind the system clock, negative, it is early.

Positive values indicate the drifted clock is behind the system clock, negative, it is early.

Returns

qint64

Here is the caller graph for this function:

driftChanged

void DriftingDateTimeSingleton::driftChanged ( qint64 new_drift ) const

signal

Communicate the drift change to anyone who want to know.

This outgoing signal is the main motivation for introducing this class in the first place, rather than just using static methods.

Here is the caller graph for this function:

getSingleton()

DriftingDateTimeSingleton & DriftingDateTimeSingleton::getSingleton ( )

static

Get the singleton instance.

The first thread that calls this is the thread the singleton lives in.

Returns

DriftingDateTimeSingleton&

Here is the call graph for this function:

Here is the caller graph for this function:

onPlumbingCompleted

void DriftingDateTimeSingleton::onPlumbingCompleted ( ) const

slot

Emits to the driftChanged signal (as per TwoPhaseSignal contract).

Emits to the driftChanged signal (as per TwoPhaseSignal contract).

Here is the call graph for this function:

setDrift

void DriftingDateTimeSingleton::setDrift ( qint64 ms )

slot

Set the drift.

Set the drift.

Parameters

ms

Here is the call graph for this function:

Here is the caller graph for this function:

---

The documentation for this class was generated from the following files:

• JS8_Main/DriftingDateTime.h
• JS8_Main/DriftingDateTime.cpp