Extended ranges required for dates and date-times

[Jason Harris]

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

FWIW, in KStars, Time Zone data is attached to the GeoLocation object, 
not the ExtDateTime object.  So, we keep track of Universal Time in the 
application, then if you need local time for a GeoLocation* named "geo", 
you do something like:

ExtDateTime LocalTime = geo->UTtoLT( UniversalTime );


which seems to make more OOP sense.  However, I do understand that 
KDE-wide we don't have classes describing geographic locations...

Jason