KDateTime: revised version
lists at astrojar.org.uk
Tue Nov 22 10:08:22 GMT 2005
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
>I had an idea but I am not ure how ueful or easy it would be. It would to have
>- 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.
>Also to add on RFC 2822 dates, KDateTime should perhaps offer the unlocalized
>date/time somehow. (QDateTime::toString offers only the localized date/time
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!
KAlarm author & maintainer.
More information about the kde-core-devel