KDateTime: new revised version
nicolasg at snafu.de
Sat Nov 26 17:24:42 GMT 2005
On Friday 25 November 2005 13:28, David Jarvie wrote:
> On Friday 25 November 2005 11:30, Shaheed wrote:
> >On Thursday 24 November 2005 13:13, Nicolas Goutte wrote:
> >As I suggest above, if we treat the "-0500" simply as an offset from GMT,
> > with no reference to timezone (or KTimezone*), doesn't this use case work
> > exactly as one might expect?
> I earlier today proposed that KDateTime should be able to store an offset
> from UTC (so as to retain information from ISO 8601 strings),
> and Nicholas
> thought that this should be treated as a local time, not as UTC.
As this answer seemed for me to be light-years away from what I have answered,
I have tried to think more deeply about the problem that we have in this
After thinking, I think the problem is that "local time" is defined in two
ways, which are not exactly compatible, if not conflicting:
- a time in the system's time zone. (That is what the C library and QDateTime
- a time (wall time) in an arbitrary place. (That is probably the common
The problem of my answers of this thread is that I have never thought about
the common sence meaning of "local time".
So to start again the discussion on a clean base.
A QDateTime which is Qt::LocalTime should be transformed by default to a
KDateTime having the current system's timezone. (Of course, the other
constructors can have parameters to tweak such a transformation in a
To be back to the answer above, I think that a date/time with an offset is
different than a pure UTC date, especially because it has an offset.
(As I have wriiten in an answer to Shaheed's private email, nobody would buy
clocks and watches if they could only display UTC.)
Also for KDateTime, for member function returning if the date/time is UTC, a
date with a non-zero offset should return false. Similarly the member
function for testing if it is a local time (in the sence of QDateTime) should
return false too (as we do not know if the offset corrsepond to the system's
timezone, even if perhaps the time offset would match.)
Of course perhaps there would be another member function for testing if a date
is neither UTC nor the local time (again in QDateTime's sence). For such a
function, a dtae/time with non-zero offset should return true.
A little side note: perhaps we must be careful what the UTC checking function
returns in the case of a UTC timezone like UTC, Zulu, Universal, UCT, GMT and
all the other alternative names (already the Etc subdirectory seems to have
them all again). (I have not checked the current code to see if it already
return true in such cases.)
As for the "local time" uncertainty, perhaps it would be useful to add a note
in the Doxygen comment of KDateTime to explain the two meanings.
Now that I was more explicit, perhaps less misunderstandings will happen in
the rest of the discussion.
> But I
> agree with what you say above, and I think that the "UTC with offset"
> variant should simply be treated as UTC. The KDateTime class should treat
> the offset merely as a comment, and only use it in the toString() method.
I do not mind the internal representation. What I would like is that for
interaction with other formats than the internal formats, that the time
offset is not lost (unlike what Shaheed seems to prefer).
> David Jarvie.
> KAlarm author & maintainer.
Have a nice day!
More information about the kde-core-devel