KDateTime: revised version

[Nicolas Goutte]

On Monday 21 November 2005 19:06, David Jarvie wrote:
> On Monday 21 Nov 2005 13:15, Nicolas Goutte wrote:
> > On Monday 21 November 2005 13:27, David Jarvie wrote:
> > > On Monday 21 Nov 2005 06:47, Simon Hausmann wrote:
> > > > On Monday 21 November 2005 03:14, David Jarvie wrote:
> > > > > Attached is revised code for a new KDateTime class. There are
> > > > > various minor changes in response to comments.
> > > >
> > > > [...]
> > > >
> > > > Just one thing I noticed while skimming over the patch:
> > > >
> > > > [ snip ]
> > > > /********************************************************************
> > > >** ** ** ** ?**
> > > > ?** DateTimeParser and FormatSection classes are based on QDateTime
> > > > internals: ?**
> > > > ?** Copyright (C) 1992-2005 Trolltech AS. All rights reserved.
> > > > ?**
> > > > ?** This file is part of the QtCore module of the Qt Toolkit.
> > > > ?**
> > > > ?** This file may be used under the terms of the GNU General Public
> > > > ?** License version 2.0 as published by the Free Software Foundation
> > > > ?** and appearing in the file LICENSE.GPL included in the packaging
> > > > of ?** this file. ?Please review the following information to ensure
> > > > GNU ?** General Public Licensing requirements will be met:
> > > > ?** http://www.trolltech.com/products/qt/opensource.html
> > > > [ snip ]
> > > >
> > > > This means the code cannot be included in kdelibs unless we change
> > > > your licensing policy.
> > >
> > > I'm not sure whether we need to mention the Qt licence stuff for the
> > > parts lifted from Qt. The main thing seems to be that it stipulates the
> > > use of GPL version 2 (and no other version). Can we remove the Qt
> > > licence declaration and still comply with their licensing requirements?
> >
> > 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 )


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

Have a nice day!