KDateTime: revised version
lists at astrojar.org.uk
Tue Nov 22 22:58:12 GMT 2005
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.)
KAlarm author and maintainer.
More information about the kde-core-devel