KDateTime: revised version

[David Jarvie]

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.

> > >Also to add on RFC 2822 dates, KDateTime should perhaps offer the
> > > unlocalized date/time somehow. (QDateTime::toString offers only the
> > > localized date/time for Qt::TextDate.)
> >
> > That seems a good idea.
> >
> > The fromString() and toString() functions are certainly turning out to
> > need more coding effort than the rest of this class put together!
>
> Yes, perhaps, but the class needs some interface to "real-life" date/time,
> interacting to the various C library's time structures is not enough.

I have no argument against the need for the fromString() and toString() 
methods which you advocate. It was just an observation about something which 
I hadn't properly anticipated!

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