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

[Atlant Schmidt]

Thiago:

> >   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!
>
> Leap seconds are not used to adjust for inaccuracies in the
> year versus the revolution around the Sun (that's what the
> leap day is for), they are to adjust to variations in the
> in the rotation versus the day. The rotation slows down
> and speeds up, which is why leap seconds are added and
> removed.

  You seem to have read something I didn't write.

  Please see:

    http://www.leaphour.com/


  The movement to standardize the year is an entirely different
  one. Please see:

    http://www.newscientist.com/article/dn20423-push-to-define-year-sparks-time-war.html


                              Atlant


-----Original Message-----
From: qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com [mailto:qt-interest-bounces+aschmidt=dekaresearch.com at qt.nokia.com] On Behalf Of Thiago Macieira
Sent: Friday, May 13, 2011 16:51
To: qt-interest at qt.nokia.com
Subject: Re: [Qt-interest] New Date and Time Features in Qt5?

On Friday, 13 de May de 2011 15:35:26 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:

Used in, yes. Using Qt generic classes to do the value of the application? No.

If the application's objective is to be extremely precise to leap seconds, it
should not rely on Qt classes to do exactly that.

>     o Atomic clocks
>     o GPS Receivers
>     o Astronomical applications?
>
>   Any of those are *CERTAINLY exposed to Leap Seconds
>   several times a year (on average, though not lately).

Well, where "several" means "zero, one or two". And it hasn't happened in many
years. And the proposal is to get rid of them.

>   And, in fact, so is any application that actually
>   tries to handle time in an completely-accurate fashion
>   (financial trading apps, etc.)

Oh, no. Leap seconds are not there. Civilian calendars drop the leap second as
soon as it's passed. Only the clock slows down a while.

The Unix time_t counts the number of seconds since 1st of January, 1970,
adjusted for leap seconds. Whenever a leap second is added, the epoch gets one
second added. Whenever a leap second is removed, the epoch moves back by 1
too. So in other words, QDateTime represents time in Unix Time, projected to
the past and speculative to the future. If you need to adjust to proper UTC,
you just need to use your own Unix-time-to-UTC or TA1 conversion routines.

In any case, QTime stores the number of milliseconds since midnight. So it can
represent a leap second: the values from 86400000 through 86400999 are in the
leap second (if there is a leap second added, it is always 23:59:60 UTC on
June 30 or December 31).

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

Leap seconds are not used to adjust for inaccuracies in the year versus the
revolution around the Sun (that's what the leap day is for), they are to
adjust to variations in the in the rotation versus the day. The rotation slows
down and speeds up, which is why leap seconds are added and removed.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message.

Thank you.

Please consider the environment before printing this email.