KDateTime: revised version

Nicolas Goutte nicolasg at snafu.de
Thu Nov 24 00:35:15 GMT 2005


On Tuesday 22 November 2005 23:58, David Jarvie wrote:
> 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.)

Good, so the problem is probably that we define a timezone differently.

You seem to think that a timezone is only a named timezone (defined by the 
system), while I think that a numbered-only timezone is valid too. (Peronally 
I would not even try to find a named timezone from an offset.)

(I am jut thinking: has Windows any named timezone? How could this class be 
used in Windows?)


... a little later:

However I do not understand. QDateTime can only be local or UTC. But we know 
the local time zone of a system, don't we?

Have a nice day!






More information about the kde-core-devel mailing list