KDateTime: revised version

[David Jarvie]

On Tuesday 22 Nov 2005 15:52, Nicolas Goutte wrote:
> On Tuesday 22 November 2005 16:25, Nicolas Goutte wrote:
> > 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:
>
> (...)
>
> > static QDateTime fromString(const QString &string, Qt::DateFormat format
> > = Qt::ISODate);
> >
> > static QDateTime fromString(const QString &string, const QString
> > &format);
>
> I am thinking: if we have no implicit conversion from QDateTime to
> KDateTime then those two static functions should perhaps return a KDateTime
> instead of QDateTime.

The problem with returning a KDateTime is that the time zone cannot be deduced 
from the given parameters. I think that it is better to return a QDateTime 
which actually contains as much information as is possible, rather than 
mislead people into thinking that the UTC offset in the time string can get 
converted into a time zone.

> > static KDateTime fromString(const QString &string, const QString &format,
> > const KTimezones &zones, bool utcIfAmbiguous = false);

The KTimezones parameter is essential if any real attempt is to be made to 
deduce a time zone. Even then, it won't necessarily work if KTimezones holds 
many time zones and only a UTC offset is supplied in the time string. A time 
zone name is the only way to unambiguously define a time zone in the string. 
(Or of course a full time zone definition, which would be completely unwieldy 
to present to a user.)

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