KDateTime: new revised version
nicolasg at snafu.de
Tue Nov 29 10:29:23 GMT 2005
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
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!
More information about the kde-core-devel