KDateTime: new revised version

[Nicolas Goutte]

On Sunday 27 November 2005 17:34, David Jarvie wrote:
> On Sunday 27 Nov 2005 11:34, Shaheed wrote:
> > On Sunday 27 November 2005 10:28, Nicolas Goutte wrote:
> > > If we have to choose, then I think that this is clearer. (Even if I do
> > > not like the RFC2822 part in the class name, as time offsets are not at
> > > all RFC2822-specific.)
> >
> > How about KOffsetTimezone* then?
> >
> > > > 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.

That is why I would like an use-case before we go anyway near such a 
direction. However there do not seem to be much of a use, except the internal 
needs of KDateTime.

> Would it actually have any
> standalone uses, or would it be sufficient for KDateTime to handle it
> internally? 

For start, I think that KDateTime should handle it internally.

(That why I think that the conversion would be in an external class, if 
needed, as probably it will come from a need of an application; therefore 
starting as non-kdelibs code.)

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

Have a nice day!