KDateTime: new revised version

[Nicolas Goutte]

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

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 
assume.)
- a time (wall time) in an arbitrary place. (That is probably the common 
English sence.)

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 
different way.)

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.
> http://www.astrojar.org.uk/linux/kalarm.html

Have a nice day!