Extended ranges required for dates and date-times

[David Jarvie]

On Thursday 9 February 16:19, Frans Englich wrote:
>On Thursday 09 February 2006 14:59, David Jarvie wrote:
>> 2)  What class names should be used? That would depend on whether the
>> ExtDate classes were made the standard KDE classes or not. If so, the names
>> KDate and KDateTime would be the obvious ones, which would mean that the
>> existing KDateTime which handles time zones as well would have to be
>> renamed, perhaps to KZoneDateTime, KDateTimeZone or KDateTimeTZ. If they
>> were used as an adjunct to QDate/QDateTime, KExtDate and KExtDateTime might
>> be the choice, so that KDateTime's name could be left unchanged.
>
>I wouldn't focus so much on what the classes do. When handling with a date 
>value the main point is that it's a date, not that it behind the curtains 
>handles large dates in the rare cases it is needed, I think. Therefore, I 
>would go for simple names such as KDate instead of KExtDate(and if the latter 
>is nevertheless chosen, an easily understandable name such as KExtendedDate).
>
>In short: KDate, as QDate but with extended range; KDateTime, as QDateTime 
>with extended range(as KDate) and timezone/zone offset handling.
>
>Of course, as discussed with Jarvie, the "perfect" solution would be 
something 
>in the direction of:
>
>KTime: as QTime plus zone offset handling
>KDate: as QDate plus zone offset handling and extended range
>KDateTime: as QDateTime plus zone offset handling and extended range
>
>This would be the ultimate solution to what currently is not possible: to 
>store only a time or only a date value with zone offset handling(because the 
>class that do zone offset handling, KDateTime, stores both date and time). 
>But that would require a lot of work.

I'm not convinced that the basic classes should include time zone handling. 
I'd prefer to see basic classes handling date, time and date/time, with time 
zones incorporated in a different class. For many applications, time zones are 
irrelevant. But if the consensus was for incorporating time zones (or in the 
case of KTime, UTC time offsets only) in the basic classes, I would have no 
strong objection.

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