KDateTime: revised version

[Nicolas Goutte]

On Thursday 24 November 2005 11:49, David Jarvie wrote:
> 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.

To repeat what I have written in the other email, QDateTime's local time is 
not of an unknown timezone but of the current one of the computer system (as 
that is how th C library is working).

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

Personally I do not mind that you would map it to UTC.

However I suppose that a user would be more able to read a date/time with one 
hour offset than one that has the full offset to UTC.

(And for my use case of PO files, I really cannot create a named timezone for 
it, and I suppose that the kdepim developers will have the same problem in 
many situations. So one can only read a date/time with a numeric offset and 
try to convert it to the local time of the user (or of a time zone that the 
user has chosen instead, e.g. UTC.))

Have a nice day!

>
(...)