KDateTime: new revised version

[David Jarvie]

On Saturday 26 November 2005 17:24, Nicolas Goutte wrote:
>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".

As I said in a previous posting, I agree that there needs to be this 
distinction - via the enum values LocalZone and ClockTime. I have already been 
recoding the class to introduce this.

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

If it is not considered to be UTC, then if the date/time component is returned 
via dateTime(), it would return the "local" time (i.e. the UTC time plus the 
UTC offset). For example, if the time was [date] 02:00 +0300, then dateTime() 
would return a time part of 05:00. In this case, I would probably store the 
time as a local time (i.e. Qt::LocalTime) of 05:00, and then the UTC offset 
would as I previously proposed only ever be used by toString() which would for 
an ISO 8601 format return [date] 02:00 +0300.

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

I don't think that we can return "UTC" unless it is constructed with a UTC 
specifier, or if it is constructed with the KTimezones::utc() KTimezone. 
Otherwise, we can't be sure that it really is UTC, and would return false. (It 
might in addition be possible to add a function to KTimezone to check whether 
a time zone is UTC, i.e. that it always has a UTC offset of zero, and never 
undergoes any daylight savings changes. Then we could call that function to 
find if it was UTC.)
 
>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.

I have already done that for the next version of the code.

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

See above.

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