KDateTime: revised version

[David Jarvie]

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.

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

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