Date/time class changes to handle extended date ranges

[David Jarvie]

On Monday 20 February 2006 11:15, David Faure wrote:
>On Monday 20 February 2006 11:57, David Jarvie wrote:
>> On Monday 20 February 2006 10:43, 'R.F. Pels' wrote:
>> >On Monday 20 February 2006 10.36, David Jarvie wrote:
>> >> So far, unless I'm mistaken, nobody else has agreed with you on the naming
>> >> issue. So unless that changes, and because I disagree with you, I will use
>> >> the names which I proposed.
>> >
>> >Great... Then I /do/ hope you also propose to adjust KDateInternalXXX, 
>> >KDatePicker, KDateTable, KDateTimeWidget, KDateValidator and KDateWidget to 
>> >use the KDate class. After all, the name you propose creates the expectation 
>> >that they all work with a KDate object.
>> 
>> I think that you're taking too narrow a view on this. To repeat, unless a 
consensus 
>> agrees with you, I won't change the proposed class names.
>
>Well, I agree with you that the class name is fine (KDate == the date class 
>provided by KDE; doesn't say anything about its relation to QDate).
>
>However Ruurd has a point: it would make sense that all KDate* widgets can 
>actually work with KDate objects. If the APIs are similar then it shouldn't be 
>too difficult to port them to KDate (and assuming there's a KDate(const 
>QDate&) constructor, passing QDates to those widgets would still work.

Converting the rest of kdelibs to use KDate was part of my proposal. The idea was to 
make KDate the standard date class for KDE.

But if QDate could be amended to allow a greater range of dates, that would be a 
better solution, as already mentioned in this thread earlier today. Can Trolltech be 
persuaded to relax the QDate limits?

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