KDateTime: revised version

[Nicolas Goutte]

On Tuesday 22 November 2005 23:52, David Jarvie wrote:
> On Tuesday 22 Nov 2005 15:25, Nicolas Goutte wrote:
> > On Tuesday 22 November 2005 11:08, David Jarvie wrote:
> > > On Tuesday 22 Nov 2005 4:23, Nicolas Goutte wrote:
> > > >I had an idea but I am not ure how ueful or easy it would be. It would
> > > > to have three functions:
> > > >- one reading ISO 8601 dates (which over time could be extended to
> > > > support even less used features like week or day of the year).
> > > >- one reading RFC 2822 dates (with support for older RFC 822).
> > > >- one reading a format defined by a string parameter. (You could chooe
> > > > not to support time zones on this, allowing to use directly
> > > > QDateTime::fromString, at least as first step.)
> > > >
> > > >Of course, when meaning "functions" I mean more the internal
> > > > implementation, it could still be handled by a single interface:
> > > >KDateTime::fromString ( const QString & s, Qt::DateFormat f =
> > > > Qt::TextDate )
> > >
> > > Correct me if I'm wrong, but that would require at least two
> > > interfaces, one of which would specify a format string, and the other
> > > not.
> >
> > Sorry but I am not sure to understand your answer.
> >
> > In the last code that you have made public, there is already three
> > versions of KDateTime::fromString:
> >
> > static QDateTime fromString(const QString &string, Qt::DateFormat format
> > = Qt::ISODate);
> >
> > static QDateTime fromString(const QString &string, const QString
> > &format);
> >
> > static KDateTime fromString(const QString &string, const QString &format,
> > const KTimezones &zones, bool utcIfAmbiguous = false);
>
> We surely still need at least two interfaces - one with a DateFormat
> parameter and one with a 'QString format' parameter. I don't see how they
> could be merged sensibly into a single method.

As QDateTime has also two methods, I do not think that it needs to be merged.

>
(...)

Have a nice day!