KDateTime: revised version
nicolasg at snafu.de
Tue Nov 22 15:25:47 GMT 2005
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
static QDateTime fromString(const QString &string, Qt::DateFormat format =
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.
Have a nice day!
More information about the kde-core-devel