KDateTime: next iteration

[David Jarvie]

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

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 
KStars classes.

--
David Jarvie.
KAlarm author & maintainer.
http://www.astrojar.org.uk/linux/kalarm.html