KDateTime: revised version
lists at astrojar.org.uk
Thu Nov 24 10:49:07 GMT 2005
On Thursday 24 November 2005 0:35, Nicolas Goutte wrote:
>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:
>> > (...)
>> > > 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.)
A time zone has information about daylight savings time changes, and allows you to calculate
the elapsed time between two clock times in that time zone, etc. A numbered "time zone" says
nothing about daylight savings time changes, so a simple UTC offset is just a way of
representing an absolute time. If you know that somebody sent you an email at "20:30, 31st
March 2004 +0300", you don't know what their clock time would be 100000 minutes later because
they might or might not have passed through a daylight savings change. Only the time _zone_
can tell you that.
>(I am jut thinking: has Windows any named timezone? How could this class be
>used in Windows?)
Windows definitely knows about time zones. I don't know how it represents them, but the
KSystemTimezone class will handle that. (It probably doesn't yet work with Windows - that's
just one of the jobs for the Windows port.) KDateTime uses the KTimezone class to know about
time zones, so it will automatically work on Windows once KSystemTimezone works there.
>... 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?
See my earlier posting this morning for an explanation of the difference between "local time"
and "local time zone".
KAlarm author & maintainer.
More information about the kde-core-devel