KDateTime: revised version

[David Jarvie]

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

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