[Qt-interest] New Date and Time Features in Qt5?

[Konrad Rosenbaum]

On Friday 13 May 2011, Atlant Schmidt wrote:
> Thiago:
> > Let's try again: please name two systems where
> > Qt runs where the OS reports 61-second minutes.
> 
>   I don't have any at hand, but are you saying you
>   don't *EVER* want Qt to be used in:
> 
>     o Atomic clocks
>     o GPS Receivers

If you mean the firmware of those devices: hell no! You don't want something 
as complex as Qt in there.

If you mean an extra embedded system that lets you control the low level 
stuff in a user friendly way: I don't see your problem. The extra system 
will probably have its own system clock (whether it is connected to an RTC 
or just the kernel clock) and QDateTime represents exactly this system 
clock. The clock of the low-level device needs to be wrapped in its own 
class (or classes), since it will also have its very specific behavior that 
is special to the protocol implemented by the device or even idiosyncrasies 
of the device hardware. That both the system clock and the atomic or GPS 
clocks are loosely synchronized is a completely different matter that has 
nothing to do with the fact that they count time very differently.

>     o Astronomical applications?

You mean like KStars?

I haven't looked at that application, but I suspect it has its own 
implementation of date and time calculations that fit its application model 
of date and time.

Thanks for providing the example! It shows that many of those specialized 
systems are quite incompatible:

* QDateTime represents the system clock of the PC or whatever high-level 
multitasking, GUI oriented device it runs on, the system clock is concerned 
with keeping in sync with other networked clocks with an accuracy of several 
minutes (e.g. Kerberos requires 5min) down to about 10ms (NTP sync'ed LAN); 
it does not care what planet it is on, only what network it is embedded 
within

* atomic clocks are concerned about keeping time accurate to the nanosecond 
at a very specific frame of reference - the frame that moves with earth 
through the cosmos and has a standard gravity of 9.81 m/s^2 - they are only 
loosely related to all other clocks on the planet in that they are used at 
specific intervals to tune and reset those other clocks

* GPS has a clock system that is based on atomic clocks floating is space, 
so they are on a different frame of reference than other atomic clocks - 
namely they are in zero G and in constant motion that is different for each 
satellite, so it has to deal with those specific problems

* astronomical applications are concerned with the position of earth and an 
earth bound observer relative to the galactic plane, so its clock differs by 
roughly one day per year and it counts dates quite differently. It is almost 
completely unrelated to system time and atomic time (except by some rather 
complex calculations).

>   Any of those are *CERTAINLY exposed to Leap Seconds
>   several times a year (on average, though not lately).

I disagree. Atomic clocks are not exposed to Leap Seconds. They show us when 
leap seconds are necessary, because they keep far better time than the 
spinning of our fair planet.

A tiny, but significant distinction... ;-P

Astronomic apps are only exposed to leap seconds because they have to use 
them to convert local time to astronomic time. If they could synchronize to 
an atomic clock instead they would do different corrective calculations.

>   And, in fact, so is any application that actually
>   tries to handle time in an completely-accurate fashion

Define "completely-accurate" please. Accurate in relation to what frame of 
reference? I myself believe that my internal biological clock is completely 
accurate in relation to my own biological needs (e.g. right now it tells me 
I need some cake and I'm convinced it is right about that). Of course it is 
quite inaccurate in relation to the time I see in my clock widget on the 
screen (I wouldn't have guessed that is almost 3pm already).

>   (financial trading apps, etc.)

You mean those apps that start working at the exact time that the stock 
exchange opens, keep time accurate to about 1/10th of a second, and can 
relax when the stock exchange closes, meanwhile ignoring completely the fact 
that network lag is bigger than their supposed accuracy?

When designing one of those I wouldn't take leap seconds into consideration. 
My main concern would be to synchronize with the clocks of each stock 
exchange I connected with - and with being able to keep track of each of 
them separately. And of course with optimizing network latency effects 
better the other guy.

I always wonder why those financial guys call their stuff "real-time", when 
it is only accurate to about a second or 1/10th of a second. There are more 
demanding applications time wise (GPS for example).

>   Perhaps you should join the movement that's trying
>   to stamp-out Leap Seconds in favor of the once-
>   every-900-years (or so) Leap Hour? ;-) That idea
>   would certainly make life easier for us programmers!

I'm more in favor of the accurate spin. We can fly to space, we can make 
clocks that count nanoseconds, lasers and cameras that are work on the 
femtosecond scale, why can't we make that planet spin more accurately? ;-)

Time is one of the most interesting and most complex topics once you get 
beyond the notion that it is the same for everyone. Whole libraries have 
been filled with books about that topic. You can't possibly expect support 
for each system of time in one single class or even one single library.


	Konrad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20110515/6c031adc/attachment.bin