KDateTime: new revised version

[David Jarvie]

On Sunday 27 Nov 2005 16:40, Shaheed wrote:
> On Sunday 27 November 2005 16:34, David Jarvie wrote:
> > > > > In both cases, the implication is that the toString()/fromString()
> > > > > methods in KTimeDate would be delegated to an appropriate KTimezone
> > > > > subclass using a virtual method.
> > >
> > > I think the key question remaining is whether David thinks this makes
> > > sense (since he owns KDateTime and the other relevant classes).
> > >
> > > > > The latter would allow apps to easily convert between the two, but
> > > > > would imply that different entries from different sources would not
> > > > > always have the same info
> >
> > If we introduced a KOffsetTimezone class, it would be quite a simple
> > class. Because it wouldn't be possible to convert easily between it and
> > KTimezone, I'm not sure whether it would really be useful. Would it
> > actually have any standalone uses, or would it be sufficient for
> > KDateTime to handle it internally? Who would actually want to do any
> > calculations involving it, other than via KDateTime? KTimezone (and its
> > derivatives) are needed because processing real time zones is quite
> > complex, but I remain to be convinced about KOffsetTimezone.
>
> I agree that KOffsetTimezone is very simple. My point was more around the
> delegation of the toString()/fromString() functions: rather than KDateTime
> hardcoding the behaviour, it could pickup whatever logic was needed from
> the KTimezone derivative.

I don't really see the benefit of handing off the toString()/fromString() 
functions to another class - the KOffsetTimezone class would have to 
duplicate all the formatting functions which are currently handled by 
KDateTime. And I don't think that KOffsetTimezone, if it is created, should 
be derived from the current KTimezone, since the two ways of dealing with 
time zones are incompatible and conversions between the two aren't 
necessarily possible. Currently, KTimezone and its derivatives work together 
and you can convert between them - that wouldn't be the case with 
KOffsetTimezone.

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