KDateTime: next iteration
lists at astrojar.org.uk
Tue Nov 29 13:32:47 GMT 2005
On Tuesday 29 November 2005 10:55, Nicolas Goutte wrote:
>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
>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...
>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.
Extending the range back before the Gregorian calendar started (and of course, it started later in some
countries than in others) would create its own problems - secsTo(), daysTo(), addSecs(), addDays(), etc.
would all be potentially inaccurate. So I'm not sure about trying to extend backwards. Jason Harris already
suggested this (http://lists.kde.org/?l=kde-core-devel&m=113151726006930&w=2) since KStars already has an
extended date/time class.
And of course the other issue with extending the range backwards is that there was no such thing as a time
zone more than a century or so ago. So what I see as the main purpose of the KDateTime class - to be able
to handle time zone information automatically - would be irrelevant at such dates. I think that for anyone
who wants extended range date handling, it might be better to use a separate class, perhaps based on the
KAlarm author & maintainer.
More information about the kde-core-devel