KDateTime: revised version

[Nicolas Goutte]

On Tuesday 22 November 2005 11:08, David Jarvie wrote:
> On Tuesday 22 Nov 2005 4:23, Nicolas Goutte wrote:
> >On Monday 21 November 2005 19:06, David Jarvie wrote:
> >> On Monday 21 Nov 2005 13:15, Nicolas Goutte wrote:
> >> > Qt is code is GPL (or the other Qt licenses). So it is not compatible
> >> > with the licenses required for code being in kdelibs.
> >> >
> >> > Leaving out the copyright does not change the fact about Qt's license.
> >>
> >> Evidently I'll have to write something myself instead, and not use the
> >> Qt code.
> >
> >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);

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

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

Have a nice day!