KDateTime: next iteration

[Nicolas Goutte]

On Tuesday 29 November 2005 11:33, Brad Hards wrote:
> On Tuesday 29 November 2005 21:07 pm, Nicolas Goutte wrote:
> > On Tuesday 29 November 2005 10:34, Brad Hards wrote:
> > > Any thoughts about handling leap seconds?
> >
> > Where do you see the need?
>
> I am interested in conversion between GPS time and UTC, however I am sure
> that there are a lot of people who care about identifying activities to
> within a second (security logging, astronomy, scientific experiment
> control, and almost certainly more)
>
> > (Also the problem is QTime, which does not support 60 and 61 seconds.)
>
> I haven't looked at the detail, I was just querying about whether there was
> any intention to support it, and if so, how. If it is an implementation
> limit that there is no support for leap seconds, that is probably worth
> documenting.

If the support is added, then I suppose that KDateTime should not be based on 
QDateTime, but that it should store its data by itself: year, month... 
seconds, milliseconds.

And when converting to QDateTime, then probably second 60 and 61 should be 
forced to 59.

Another advantage of doing so would be that we would have the full iSO 8601 
range (including negative years), and not the 1753  year limit that Qt has, 
see bug #89286.

>
> Brad

Have a nice day!